[libvirt] [PATCH] docs: kbase: Add a section explaining how to verify SEV from the guest

[Daniel P. Berrangé]

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