On Mon, Sep 23, 2019 at 11:06:34AM +0100, Daniel P. Berrangé wrote: > On Fri, Sep 20, 2019 at 01:47:09PM +0200, Erik Skultety wrote: > > Commit 50dfabbb59 forgot to add this important bit on how to check that > > all the changes to the XML actually worked. > > --- > > docs/kbase/launch_security_sev.html.in | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > > > diff --git a/docs/kbase/launch_security_sev.html.in b/docs/kbase/launch_security_sev.html.in > > index 923bb52b25..4b8e06ccc1 100644 > > --- a/docs/kbase/launch_security_sev.html.in > > +++ b/docs/kbase/launch_security_sev.html.in > > @@ -349,6 +349,18 @@ EOF</pre> > > ... > > </domain></pre> > > > > + <h2><a id="Guest">Checking SEV from within the guest</a></h2> > > + <p> > > + After making the necessary adjustments discussed in > > + <a href="#Configuration">Configuration</a>, the VM should now boot > > + successfully with SEV enabled. You can then verify that the guest > > + enabled with SEV by running: > > + </p> > > + > > + <pre> > > +# dmesg | grep -i sev > > +AMD Secure Encrypted Virtualization (SEV) active</pre> > > + > > My understanding of SEV, was that it should be impossible to boot the > SEV enabled kernel at all if SEV was not active on the host. > > Given SEV is a security critical mechanism though, looking at kernel dmesg > doesn't feel like a satisfactory approach for validating the host really > did boot your SEV enabled kernel, as opposed to replacing it with a backdoor > kernel which simply prints this magic to dmesg. > > So I'm wondering what really is the secure way to unambigously prove that > you've booted the original SEV enabled kernel & not an imposter ? For that you'd need to do the measurement/fingerprint of the firmware you're loading (+ encrypt the drive to ensure noone has tampered with the disk from the outside either) to make sure you're not booting with a rogue firmware before you actually boot the guest. Weird as it sounds, enforcement of the measurement wasn't intentionally made the default by AMD (I don't remember the reason anymore). In order to do the measurement you need to use SEV-specific certificates to both verify the chain of trust and query the measurement in an encrypted manner. The catch is that the tool to generate these (we're not talking about x509 or anything like it) is a community tool made by AMD, still mostly used for testing only and IMO not suited for production. I know the docs doesn't cover this usage, but I'm just waiting to see when (and if) we're going to get a packaged, stable, tested, and maintained tool to do this since we're talking about critical security with this feature. Anyhow, using dmesg to check that the guest kernel is SEV enabled corresponds to what AMD recommended in their guide, but maybe there's a different way. Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
