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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jan 30, 2019 at 09:06:30AM +0100, Erik Skultety wrote:
> Thanks for ^this bit which helped me understand the bits below. When I read the
> man page yesterday the first question was, okay, how do I figure out whether
> the file capabilities bit is set? Well, use xattrs...which didn't return
> anything, so I was puzzled what exactly it should look like, but now that you
> explained that most binaries actually lack the file capabilities, I see the
> issue clearly :).

The commands you want to experiment with are "getcap" and "setcap" eg

# getcap  qemu-system-x86_64
# setcap cap_dac_override=+ep qemu-system-x86_64
# getcap  qemu-system-x86_64
qemu-system-x86_64 = cap_dac_override+ep
# setcap  cap_dac_override= qemu-system-x86_64
# getcap  qemu-system-x86_64
qemu-system-x86_64 =
# setcap -r qemu-system-x86_64
# getcap  qemu-system-x86_64
# 



> > +
> >      ret = 0;
> >   cleanup:
> >      return ret;
> >
> >
> > 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.

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 :|