All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Dov Murik <dovmurik@linux.ibm.com>
Cc: Cole Robinson <crobinso@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Singh, Brijesh" <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: adding 'official' way to dump SEV VMSA
Date: Thu, 14 Apr 2022 09:25:53 +0100	[thread overview]
Message-ID: <YlfakQfkZFOpKWeU@work-vm> (raw)
In-Reply-To: <462cbf77-432a-c09c-6ec9-91556dc0f887@linux.ibm.com>

* Dov Murik (dovmurik@linux.ibm.com) wrote:
> Hi Cole,
> 
> On 13/04/2022 16:36, Cole Robinson wrote:
> > Hi all,
> > 
> > SEV-ES and SEV-SNP attestation require a copy of the initial VMSA to
> > validate the launch measurement. For developers dipping their toe into
> > SEV-* work, the easiest way to get sample VMSA data for their machine is
> > to grab it from a running VM.
> > 
> > There's two techniques I've seen for that: patch some printing into
> > kernel __sev_launch_update_vmsa, or use systemtap like danpb's script
> > here: https://gitlab.com/berrange/libvirt/-/blob/lgtm/scripts/sev-vmsa.stp
> > 
> > Seems like this could be friendlier though. I'd like to work on this if
> > others agree.
> > 
> > Some ideas I've seen mentioned in passing:
> > 
> > - debugfs entry in /sys/kernel/debug/kvm/.../vcpuX/
> > - new KVM ioctl
> > - something with tracepoints
> > - some kind of dump in dmesg that doesn't require a patch
> > 
> > Thoughts?
> 
> 
> Brijesh suggested to me to construct the VMSA without getting any info from
> the host (except number of vcpus), because the initial state of the vcpus
> is standard and known if you use QEMU and OVMF (but that's open for discussion).
> 
> I took his approach (thanks Brijesh!) and now it's how we calculate expected
> SNP measurements in sev-snp-measure [1].  The relevant part for VMSA construction
> is in [2].
> 
> I plan to add SEV-ES and SEV measurements calculation to this 
> library/program as well.

Everyone seems to be writing one; you, Dan etc!

I think I agree the right way is to build it programmatically rather
than taking a copy from the kernel;  it's fairly simple, although the
scripts get increasingly hairy as you deal with more and more VMM's and
firmwares.

I think I'd like to see a new ioctl to read the initial VMSA, primarily
as a way of debugging so you can see what VMSA you have when something
goes wrong.

Dave

> 
> [1] https://github.com/IBM/sev-snp-measure
> [2] https://github.com/IBM/sev-snp-measure/blob/main/sevsnpmeasure/vmsa.py
> 
> -Dov
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Dov Murik <dovmurik@linux.ibm.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Cole Robinson <crobinso@redhat.com>,
	"Singh, Brijesh" <brijesh.singh@amd.com>
Subject: Re: adding 'official' way to dump SEV VMSA
Date: Thu, 14 Apr 2022 09:25:53 +0100	[thread overview]
Message-ID: <YlfakQfkZFOpKWeU@work-vm> (raw)
In-Reply-To: <462cbf77-432a-c09c-6ec9-91556dc0f887@linux.ibm.com>

* Dov Murik (dovmurik@linux.ibm.com) wrote:
> Hi Cole,
> 
> On 13/04/2022 16:36, Cole Robinson wrote:
> > Hi all,
> > 
> > SEV-ES and SEV-SNP attestation require a copy of the initial VMSA to
> > validate the launch measurement. For developers dipping their toe into
> > SEV-* work, the easiest way to get sample VMSA data for their machine is
> > to grab it from a running VM.
> > 
> > There's two techniques I've seen for that: patch some printing into
> > kernel __sev_launch_update_vmsa, or use systemtap like danpb's script
> > here: https://gitlab.com/berrange/libvirt/-/blob/lgtm/scripts/sev-vmsa.stp
> > 
> > Seems like this could be friendlier though. I'd like to work on this if
> > others agree.
> > 
> > Some ideas I've seen mentioned in passing:
> > 
> > - debugfs entry in /sys/kernel/debug/kvm/.../vcpuX/
> > - new KVM ioctl
> > - something with tracepoints
> > - some kind of dump in dmesg that doesn't require a patch
> > 
> > Thoughts?
> 
> 
> Brijesh suggested to me to construct the VMSA without getting any info from
> the host (except number of vcpus), because the initial state of the vcpus
> is standard and known if you use QEMU and OVMF (but that's open for discussion).
> 
> I took his approach (thanks Brijesh!) and now it's how we calculate expected
> SNP measurements in sev-snp-measure [1].  The relevant part for VMSA construction
> is in [2].
> 
> I plan to add SEV-ES and SEV measurements calculation to this 
> library/program as well.

Everyone seems to be writing one; you, Dan etc!

I think I agree the right way is to build it programmatically rather
than taking a copy from the kernel;  it's fairly simple, although the
scripts get increasingly hairy as you deal with more and more VMM's and
firmwares.

I think I'd like to see a new ioctl to read the initial VMSA, primarily
as a way of debugging so you can see what VMSA you have when something
goes wrong.

Dave

> 
> [1] https://github.com/IBM/sev-snp-measure
> [2] https://github.com/IBM/sev-snp-measure/blob/main/sevsnpmeasure/vmsa.py
> 
> -Dov
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2022-04-14  8:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13 13:36 adding 'official' way to dump SEV VMSA Cole Robinson
2022-04-13 13:36 ` Cole Robinson
2022-04-14  8:19 ` Dov Murik
2022-04-14  8:19   ` Dov Murik
2022-04-14  8:25   ` Dr. David Alan Gilbert [this message]
2022-04-14  8:25     ` Dr. David Alan Gilbert
2022-04-19 13:33     ` Cole Robinson
2022-04-19 13:33       ` Cole Robinson
2022-04-19 14:23       ` Dr. David Alan Gilbert
2022-04-19 14:23         ` Dr. David Alan Gilbert
2022-04-19 17:04       ` Daniel P. Berrangé
2022-04-19 17:04         ` Daniel P. Berrangé
2022-04-19 16:59 ` Daniel P. Berrangé
2022-04-19 16:59   ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YlfakQfkZFOpKWeU@work-vm \
    --to=dgilbert@redhat.com \
    --cc=berrange@redhat.com \
    --cc=brijesh.singh@amd.com \
    --cc=crobinso@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thomas.lendacky@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.