[libvirt] [PATCH] docs: kbase: Add a section explaining how to verify SEV from the guest
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> + <h2><a id="Limitations">Limitations</a></h2> <p> Currently, the boot disk cannot be of type virtio-blk, instead, virtio-scsi -- 2.20.1
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:
-EPARSE You can then verify that the guest has SEV enabled by running or You can verify that SEV is enabled by running this command in the guest
+ </p> + + <pre> +# dmesg | grep -i sev +AMD Secure Encrypted Virtualization (SEV) active</pre> + <h2><a id="Limitations">Limitations</a></h2> <p> Currently, the boot disk cannot be of type virtio-blk, instead, virtio-scsi -- 2.20.1
Reviewed-by: Ján Tomko <jtomko@redhat.com> Jano
On Mon, Sep 23, 2019 at 10:11:47AM +0200, Ján Tomko 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:
-EPARSE
yep, I agree :).
You can then verify that the guest has SEV enabled by running
I'll go with ^this one.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Thanks, Erik
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 :|
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. Erik
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 :|
participants (3)
-
Daniel P. Berrangé -
Erik Skultety -
Ján Tomko