On Wed, Jul 20, 2022 at 11:12:56PM +0000, Yang, Lin A wrote: > > This version is a bit better than the previous one. But we're at version > > 13 and I am still unable to even start a guest. Please, make sure that this > > basic functionality works in v14, because this is plain waste of precious > > review bandwidth. > > > > Anyway, as usual, I've uploaded my suggested fixes here: > > > > https://gitlab.com/MichalPrivoznik/libvirt/-/commits/sgx/ > > Sorry to hear it didn't work in your environment. We definitely tested it > several times and it works well for both QEMU 6.2.0 and 7.0.0. > > Let me try to reproduce it with the domain xml you shared before. > > By my best guess, if you see "qemu-system-x86_64:***: > invalid object type: memory-backend-epc" error, it means QEMU didn't > get enough permission to launch SGX VM. > > Pls add /dev/sgx_vepc, /dev/sgx_enclave and /dev/sgx_provision to the > "cgroup_device_acl" list in /etc/libvirt/qemu.conf. QEMU requires those access > to assign EPC, but it was denied by libvirt’s cgroup controllers by default. > > cgroup_device_acl = [ > "/dev/null", "/dev/full", "/dev/zero", > ... > "/dev/sgx_vepc", > "/dev/sgx_enclave”, > "/dev/sgx_provision” > ] > > Also in /etc/libvirt/qemu.conf, set the runtime user to uid 0, since QEMU needs to > read and write to those sgx devices, like /dev/sgx_vepc. Unfortunately, it is owned > by root with file mode 600, so QEMU has to launch as root. > > user = "+0" > > It would be really helpful if you can use these steps to see whether it resolve > the issue. I will add a doc somewhere to include all steps are required for use to > use sgx in libvirt. The need to customize qemu.conf to change cgroups ACLs and set uid==0 makes this patch series unusal in the real world deployments. It cannot be merged with such problems existing. Are the /dev/sgx* fundamentally required to be restricted to root access only, or is it safe to make them accessible to non-root ? ie If a malicious user has access to those files, what is the impact they have ? Bear in mind that QEMU itself can be malicious if the guest compromises it. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
