docs: kbase: Add a section explaining how to verify SEV from the guest

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

Posted by Erik Skultety 4 years, 7 months ago

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>
   ...
 &lt;/domain&gt;</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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

Posted by Ján Tomko 4 years, 6 months ago

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>
>   ...
> &lt;/domain&gt;</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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

Posted by Erik Skultety 4 years, 6 months ago

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>
> >   ...
> > &lt;/domain&gt;</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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

Posted by Daniel P. Berrangé 4 years, 6 months ago

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>
>    ...
>  &lt;/domain&gt;</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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

Posted by Erik Skultety 4 years, 6 months ago

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>
> >    ...
> >  &lt;/domain&gt;</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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

Posted by Daniel P. Berrangé 4 years, 6 months ago

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>
> > >    ...
> > >  &lt;/domain&gt;</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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list