6:51 a.m.
On 1/18/19 3:39 AM, Erik Skultety wrote:
Hi,
this is a summary of a private discussion I've had with guys CC'd on this email
about finding a solution to [1] - basically, the default permissions on
/dev/sev (below) make it impossible to query for SEV platform capabilities,
since by default we run QEMU as qemu:qemu when probing for capabilities. It's
worth noting is that this is only relevant to probing, since for a proper QEMU
VM we create a mount namespace for the process and chown all the nodes (needs a
SEV fix though).
# ll /dev/sev
crw-------. 1 root root
I suggested either force running QEMU as root for probing (despite the obvious
security implications) or using namespaces for probing too. Dan argued that
this would have a significant perf impact and suggested we ask systemd to add a
global udev rule.
I proceeded with cloning [1] to systemd and creating an udev rule that I planned
on submitting to systemd upstream - the initial idea was to mimic /dev/kvm and
make it world accessible to which Brijesh from AMD expressed a concern that
regular users might deplete the resources (limit on the number of guests
allowed by the platform).
During private discussion I didn't realized that we are discussing a
probe issue hence things I have said earlier may not be applicable
during the probe. The /dev/sev is managed by the CCP (aka PSP) driver.
The /dev/sev is used for communicating with the SEV FW running inside
the PSP. The SEV FW offers platform and guest specific services. The
guest specific services are used during the guest launch, these services
are available through KVM driver only. Whereas the platform services can
be invoked at anytime. A typical platform specific services are:
- importing certificates
- exporting certificates
- querying the SEV FW version etc etc
In case of the probe we are not launch SEV guest hence we should not be
worried about depleting the SEV ASID resources.
IIRC, libvirt uses QEMP query-sev-capabilities to probe the SEV support.
QEMU executes the below sequence to complete the request:
1. Exports the platform certificates (this is when /dev/sev is accessed).
2. Read the host MSR to determine the C-bit and reduced phys-bit position
I don't see any reason why we can't give world a 'read' permission to
/dev/sev. Anyone should be able to export the certificates and query
status etc. I think the main issue is reading MSR -- which I believe is
putting a 'root' requirement. Am I missing something ?
But since the limit is claimed to be around 4, Dan
FYI, the limit on EPYC is 15.
discouraged me to continue with restricting the udev rule to only the
'kvm'
group which Laszlo suggested earlier as the limit is so small that a malicious
QEMU could easily deplete this during probing. This fact also ruled out any
kind of ACL we could create dynamically. Instead, he suggested that we filter
out the kvm-capable QEMU and put only that one in the namespace without a
significant perf impact.
- my take on this is that there could potentially be more than a single
kvm-enabled QEMU and therefore we'd need to create more than just a
single namespace.
- I also argued that I can image that the same kind of DOS attack might be
possible from within the namespace, even if we created the /dev/sev node
only in SEV-enabled guests (which we currently don't). All of us have
agreed that allowing /dev/sev in the namespace for only SEV-enabled
guests is worth doing nonetheless.
In the meantime, Christophe went through the kernel code to verify how the SEV
resources are managed and what protection is currently in place to mitigate the
chance of a process easily depleting the limit on SEV guests. He found that
ASID, which determines the encryption key, is allocated from a single ASID
bitmap and essentially guarded by a single 'sev->active' flag.
So, in conclusion, we absolutely need input from Brijesh (AMD) whether there
was something more than the low limit on number of guests behind the default
permissions. Also, we'd like to get some details on how the limit is managed,
helping to assess the approaches mentioned above.
As explained above, during the guest launch KVM drv directly call a
guest specific services from the /dev/sev so we wanted to ensure that
kvm user also has access to /dev/sev. If admin does not grant access to
/dev/sev then KVM drv should fail to execute the SEV commands.
Thanks and please do share your ideas,
Erik
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1665400
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1561113