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
next prev parent 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: linkBe 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.