Re: [libvirt] AMD SEV's /dev/sev permissions and probing QEMU for capabilities

> > though, we need a #ifdef check for existance of PR_CAP_AMBIENT > > > > > An alternative question I've been playing ever since we exchanged the last few > > > emails is that can't we wait until the ioctls are compared against permissions > > > in kernel so that upstream libvirt (and downstream too for that matter) doesn't > > > have to work around it and stick with that workaround for eternity? > > > > IIUC, the SEV feature has already shipped with distros, so we'd effectively > > be saying that what we already shipped is unusable to libvirt. This doesn't > > feel like a desirable story to me. > > It was, but it never worked, it always has been broken in this way. When we > were merging this upstream, we had a terrible shortage of machines and we had > to share, so the first person to provision the machine had already taken care > of the permissions in order to test so that led to this issue having been > overlooked until now. If it ever worked as expected and then we broke it, then > any fix from our side would make sense but otherwise I believe we should fix > this bottom up. Well technically it would work if libvirt was configured to run as root:root, but yes, that is not a normal or recommended configuration. Personally I have a preference for userspace solutions, as those are pretty straightforward to roll out to people as patches in existing releases. Deploying kernel updates is a higher bar to cross for an existing release.