On Mon, Sep 23, 2019 at 12:32:15PM +0200, Erik Skultety wrote: > 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. Ok, thanks for explaining, with that I've no objection to your docs suggestion here. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
