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