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