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