From: Michael Roth <michael.roth@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>, <x86@kernel.org>,
<linux-kernel@vger.kernel.org>, <kvm@vger.kernel.org>,
<linux-efi@vger.kernel.org>,
<platform-driver-x86@vger.kernel.org>,
<linux-coco@lists.linux.dev>, <linux-mm@kvack.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
Tom Lendacky <thomas.lendacky@amd.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Ard Biesheuvel <ardb@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
"Vitaly Kuznetsov" <vkuznets@redhat.com>,
Jim Mattson <jmattson@google.com>,
"Andy Lutomirski" <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Sergio Lopez <slp@redhat.com>, Peter Gonda <pgonda@google.com>,
"Peter Zijlstra" <peterz@infradead.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Dov Murik <dovmurik@linux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@ibm.com>,
Vlastimil Babka <vbabka@suse.cz>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Andi Kleen <ak@linux.intel.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
<tony.luck@intel.com>, <marcorr@google.com>,
<sathyanarayanan.kuppuswamy@linux.intel.com>
Subject: Re: [PATCH v8 29/40] x86/compressed/64: add support for SEV-SNP CPUID table in #VC handlers
Date: Thu, 27 Jan 2022 11:23:08 -0600 [thread overview]
Message-ID: <20220127172308.erfrpuwm6ivbdh5q@amd.com> (raw)
In-Reply-To: <20220119162747.ewgxirwcnrcajazm@amd.com>
On Wed, Jan 19, 2022 at 10:27:47AM -0600, Michael Roth wrote:
> On Wed, Jan 19, 2022 at 12:17:22PM +0100, Borislav Petkov wrote:
> > On Tue, Jan 18, 2022 at 07:18:06PM -0600, Michael Roth wrote:
> > > If 'fake_count'/'reported_count' is greater than the actual number of
> > > entries in the table, 'actual_count', then all table entries up to
> > > 'fake_count' will also need to pass validation. Generally the table
> > > will be zero'd out initially, so those additional/bogus entries will
> > > be interpreted as a CPUID leaves where all fields are 0. Unfortunately,
> > > that's still considered a valid leaf, even if it's a duplicate of the
> > > *actual* 0x0 leaf present earlier in the table. The current code will
> > > handle this fine, since it scans the table in order, and uses the
> > > valid 0x0 leaf earlier in the table.
> >
> > I guess it would be prudent to have some warnings when enumerating those
> > leafs and when the count index "goes off into the weeds", so to speak,
> > and starts reading 0-CPUID entries. I.e., "dear guest owner, your HV is
> > giving you a big lie: a weird/bogus CPUID leaf count..."
> >
> > :-)
>
Sorry for the delay, this response got stuck in my mail queue apparently.
> Ok, there's some sanity checks that happen a little later in boot via
> snp_cpuid_check_status(), after printk is enabled, that reports some
> basic details to dmesg like the number of entries in the table. I can
> add some additional sanity checks to flag the above case (really,
> all-zero entries never make sense, since CPUID 0x0 is supposed to report
> the max standard-range CPUID leaf, and leaf 0x1 at least should always
> be present). I'll print a warning for such cases, add maybe dump the
> cpuid the table in that case so it can be examined more easily by
> owner.
>
> >
> > And lemme make sure I understand it: the ->count itself is not
> > measured/encrypted because you want to be flexible here and supply
> > different blobs with different CPUID leafs?
>
> Yes, but to be clear it's the entire CPUID page, including the count,
> that's not measured (though it is encrypted after passing PSP
> validation). Probably the biggest reason is the logistics of having
> untrusted cloud vendors provide a copy of the CPUID values they plan
> to pass to the guest, since a new measurement would need to be
> calculated for every new configuration (using different guest
> cpuflags, SMP count, etc.), since those table values will need to be
> made easily-accessible to guest owner for all these measurement
> calculations, and they can't be trusted so each table would need to
> be checked either manually or by some tooling that could be difficult
> to implement unless it was something simple like "give me the expected
> CPUID values and I'll check if the provided CPUID table agrees with
> that".
>
> At that point it's much easier for the guest owner to just check the
> CPUID values directly against known good values for a particular
> configuration as part of their attestation process and leave the
> untrusted cloud vendor out of it completely. So not measuring the
> CPUID page as part of SNP attestation allows for that flexibility.
>
> >
> > > This is isn't really a special case though, it falls under the general
> > > category of a hypervisor inserting garbage entries that happen to pass
> > > validation, but don't reflect values that a guest would normally see.
> > > This will be detectable as part of guest owner attestation, since the
> > > guest code is careful to guarantee that the values seen after boot,
> > > once the attestation stage is reached, will be identical to the values
> > > seen during boot, so if this sort of manipulation of CPUID values
> > > occurred, the guest owner will notice this during attestation, and can
> > > abort the boot at that point. The Documentation patch addresses this
> > > in more detail.
> >
> > Yap, it is important this is properly explained there so that people can
> > pay attention to during attestation.
> >
> > > If 'fake_count' is less than 'actual_count', then the PSP skips
> > > validation for anything >= 'fake_count', and leaves them in the table.
> > > That should also be fine though, since guest code should never exceed
> > > 'fake_count'/'reported_count', as that's a blatant violation of the
> > > spec, and it doesn't make any sense for a guest to do this. This will
> > > effectively 'hide' entries, but those resulting missing CPUID leaves
> > > will be noticeable to the guest owner once attestation phase is
> > > reached.
> >
> > Noticeable because the guest owner did supply a CPUID table with X
> > entries but the HV is reporting Y?
>
> Or even more simply by the guest owner simply running 'cpuid -r -1' on
> the guest after boot, and making sure all the expected entries are
> present. If the HV manipulated the count to be lower, there would be
> missing entries, if they manipulated it to be higher, then there would
> either be extra duplicate entries at the end of the table (which the
> #VC handler would ignore due to it using the first matching entry in
> the table when doing lookups), or additional non-duplicate garbage
> entries, which will show up in 'cpuid -r -1' as unexpected entries.
>
> Really 'cpuid -r -1' is the guest owner/userspace view of things, so
> some of these nuances about the table contents might be noteworthy,
> but wouldn't actually affect guest behavior, which would be the main
> thing attestation process should be concerned with.
>
> >
> > If so, you can make this part of the attestation process: guest owners
> > should always check the CPUID entries count to be of a certain value.
> >
> > > This does all highlight the need for some very thorough guidelines
> > > on how a guest owner should implement their attestation checks for
> > > cpuid, however. I think a section in the reference implementation
> > > notes/document that covers this would be a good starting point. I'll
> > > also check with the PSP team on tightening up some of these CPUID
> > > page checks to rule out some of these possibilities in the future.
> >
> > Now you're starting to grow the right amount of paranoia - I'm glad I
> > was able to sensitize you properly!
> >
> > :-)))
>
> Hehe =*D
>
> Thanks!
>
> -Mike
next prev parent reply other threads:[~2022-01-27 17:23 UTC|newest]
Thread overview: 183+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 15:42 [PATCH v8 00/40] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Brijesh Singh
2021-12-10 15:42 ` [PATCH v8 01/40] x86/compressed/64: detect/setup SEV/SME features earlier in boot Brijesh Singh
2021-12-10 18:47 ` Dave Hansen
2021-12-10 19:12 ` Borislav Petkov
2021-12-10 19:23 ` Dave Hansen
2021-12-10 19:33 ` Borislav Petkov
2021-12-13 19:09 ` Venu Busireddy
2021-12-13 19:17 ` Borislav Petkov
2021-12-14 17:46 ` Venu Busireddy
2021-12-14 19:10 ` Borislav Petkov
2021-12-15 0:14 ` Venu Busireddy
2021-12-15 11:57 ` Borislav Petkov
2021-12-15 14:43 ` Tom Lendacky
2021-12-15 17:49 ` Michael Roth
2021-12-15 18:17 ` Venu Busireddy
2021-12-15 18:33 ` Borislav Petkov
2021-12-15 20:17 ` Michael Roth
2021-12-15 20:38 ` Borislav Petkov
2021-12-15 21:22 ` Michael Roth
2022-01-03 19:10 ` Venu Busireddy
2022-01-05 19:34 ` Brijesh Singh
2022-01-10 20:46 ` Brijesh Singh
2022-01-10 21:17 ` Venu Busireddy
2022-01-10 21:38 ` Borislav Petkov
2021-12-15 20:43 ` Michael Roth
2021-12-15 19:54 ` Venu Busireddy
2021-12-15 18:58 ` Venu Busireddy
2021-12-15 17:51 ` Michael Roth
2021-12-10 15:42 ` [PATCH v8 02/40] x86/sev: " Brijesh Singh
2021-12-13 22:36 ` Venu Busireddy
2021-12-10 15:42 ` [PATCH v8 03/40] x86/mm: Extend cc_attr to include AMD SEV-SNP Brijesh Singh
2021-12-13 22:47 ` Venu Busireddy
2021-12-14 15:53 ` Borislav Petkov
2021-12-10 15:42 ` [PATCH v8 04/40] x86/sev: Define the Linux specific guest termination reasons Brijesh Singh
2021-12-14 0:13 ` Venu Busireddy
2021-12-14 22:22 ` Borislav Petkov
2021-12-10 15:42 ` [PATCH v8 05/40] x86/sev: Save the negotiated GHCB version Brijesh Singh
2021-12-14 0:32 ` Venu Busireddy
2021-12-10 15:42 ` [PATCH v8 06/40] x86/sev: Check SEV-SNP features support Brijesh Singh
2021-12-16 15:47 ` Borislav Petkov
2021-12-16 16:28 ` Brijesh Singh
2021-12-16 16:58 ` Borislav Petkov
2021-12-16 19:01 ` Venu Busireddy
2021-12-10 15:42 ` [PATCH v8 07/40] x86/sev: Add a helper for the PVALIDATE instruction Brijesh Singh
2021-12-16 20:20 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 08/40] x86/sev: Check the vmpl level Brijesh Singh
2021-12-16 20:24 ` Venu Busireddy
2021-12-16 23:39 ` Mikolaj Lisik
2021-12-17 22:19 ` Brijesh Singh
2021-12-17 22:33 ` Tom Lendacky
2021-12-20 18:10 ` Borislav Petkov
2022-01-04 15:23 ` Brijesh Singh
2021-12-10 15:43 ` [PATCH v8 09/40] x86/compressed: Add helper for validating pages in the decompression stage Brijesh Singh
2021-12-17 20:47 ` Venu Busireddy
2021-12-17 23:24 ` Brijesh Singh
2022-01-03 18:43 ` Venu Busireddy
2021-12-21 13:01 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 10/40] x86/compressed: Register GHCB memory when SEV-SNP is active Brijesh Singh
2022-01-03 19:54 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 11/40] x86/sev: " Brijesh Singh
2021-12-22 13:16 ` Borislav Petkov
2021-12-22 15:16 ` Brijesh Singh
2022-01-03 22:47 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 12/40] x86/sev: Add helper for validating pages in early enc attribute changes Brijesh Singh
2021-12-23 11:50 ` Borislav Petkov
2022-01-04 15:33 ` Brijesh Singh
2022-01-03 23:28 ` Venu Busireddy
2022-01-11 21:22 ` Brijesh Singh
2022-01-11 21:51 ` Venu Busireddy
2022-01-11 21:57 ` Brijesh Singh
2022-01-11 22:42 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 13/40] x86/kernel: Make the bss.decrypted section shared in RMP table Brijesh Singh
2021-12-28 11:53 ` Borislav Petkov
2022-01-04 17:56 ` Venu Busireddy
2022-01-05 19:52 ` Brijesh Singh
2022-01-05 20:27 ` Dave Hansen
2022-01-05 21:39 ` Brijesh Singh
2022-01-06 17:40 ` Venu Busireddy
2022-01-06 19:06 ` Tom Lendacky
2022-01-06 20:16 ` Venu Busireddy
2022-01-06 20:50 ` Tom Lendacky
2021-12-10 15:43 ` [PATCH v8 14/40] x86/kernel: Validate rom memory before accessing when SEV-SNP is active Brijesh Singh
2021-12-28 15:40 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 15/40] x86/mm: Add support to validate memory when changing C-bit Brijesh Singh
2021-12-29 11:09 ` Borislav Petkov
2022-01-04 22:31 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 16/40] KVM: SVM: Define sev_features and vmpl field in the VMSA Brijesh Singh
2022-01-04 22:59 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 17/40] KVM: SVM: Create a separate mapping for the SEV-ES save area Brijesh Singh
2021-12-30 12:19 ` Borislav Petkov
2022-01-05 1:38 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 18/40] KVM: SVM: Create a separate mapping for the GHCB " Brijesh Singh
2022-01-05 18:41 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 19/40] KVM: SVM: Update the SEV-ES save area mapping Brijesh Singh
2022-01-05 18:54 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 20/40] x86/sev: Use SEV-SNP AP creation to start secondary CPUs Brijesh Singh
2021-12-10 18:50 ` Dave Hansen
2022-01-12 16:17 ` Brijesh Singh
2021-12-31 15:36 ` Borislav Petkov
2022-01-03 18:10 ` Vlastimil Babka
2022-01-12 16:33 ` Brijesh Singh
2022-01-12 17:10 ` Tom Lendacky
2022-01-13 12:23 ` Borislav Petkov
2022-01-13 12:21 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 21/40] x86/head: re-enable stack protection for 32/64-bit builds Brijesh Singh
2022-01-03 16:49 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 22/40] x86/sev: move MSR-based VMGEXITs for CPUID to helper Brijesh Singh
2021-12-30 18:52 ` Sean Christopherson
2022-01-04 20:57 ` Borislav Petkov
2022-01-04 23:36 ` Michael Roth
2022-01-06 18:38 ` Venu Busireddy
2022-01-06 20:21 ` Michael Roth
2022-01-06 20:36 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 23/40] KVM: x86: move lookup of indexed CPUID leafs " Brijesh Singh
2022-01-06 18:46 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 24/40] x86/compressed/acpi: move EFI system table lookup " Brijesh Singh
2021-12-10 18:54 ` Dave Hansen
2021-12-13 15:47 ` Michael Roth
2021-12-13 16:21 ` Dave Hansen
2021-12-13 18:00 ` Michael Roth
2022-01-11 8:59 ` Chao Fan
2022-01-05 23:50 ` Borislav Petkov
2022-01-06 19:59 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 25/40] x86/compressed/acpi: move EFI config " Brijesh Singh
2022-01-06 20:33 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 26/40] x86/compressed/acpi: move EFI vendor " Brijesh Singh
2022-01-06 20:47 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 27/40] x86/boot: Add Confidential Computing type to setup_data Brijesh Singh
2021-12-10 19:12 ` Dave Hansen
2021-12-10 20:18 ` Brijesh Singh
2021-12-10 20:30 ` Dave Hansen
2021-12-13 14:49 ` Brijesh Singh
2021-12-13 15:08 ` Dave Hansen
2021-12-13 15:55 ` Brijesh Singh
2022-01-07 11:54 ` Borislav Petkov
2022-01-06 22:48 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 28/40] KVM: SEV: Add documentation for SEV-SNP CPUID Enforcement Brijesh Singh
2022-01-07 13:22 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 29/40] x86/compressed/64: add support for SEV-SNP CPUID table in #VC handlers Brijesh Singh
2022-01-13 13:16 ` Borislav Petkov
2022-01-13 16:39 ` Michael Roth
2022-01-14 16:13 ` Borislav Petkov
2022-01-18 4:35 ` Michael Roth
2022-01-18 14:02 ` Borislav Petkov
2022-01-18 14:23 ` Michael Roth
2022-01-18 14:32 ` Michael Roth
2022-01-18 14:37 ` Michael Roth
2022-01-18 16:34 ` Borislav Petkov
2022-01-18 17:20 ` Michael Roth
2022-01-18 17:41 ` Borislav Petkov
2022-01-18 18:49 ` Michael Roth
2022-01-19 1:18 ` Michael Roth
2022-01-19 11:17 ` Borislav Petkov
2022-01-19 16:27 ` Michael Roth
2022-01-27 17:23 ` Michael Roth [this message]
2022-01-28 22:58 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 30/40] x86/boot: add a pointer to Confidential Computing blob in bootparams Brijesh Singh
2022-01-17 18:14 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 31/40] x86/compressed: add SEV-SNP feature detection/setup Brijesh Singh
2022-01-19 12:55 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 32/40] x86/compressed: use firmware-validated CPUID for SEV-SNP guests Brijesh Singh
2022-01-20 12:18 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 33/40] x86/compressed/64: add identity mapping for Confidential Computing blob Brijesh Singh
2021-12-10 19:52 ` Dave Hansen
2021-12-13 17:54 ` Michael Roth
2022-01-25 13:48 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 34/40] x86/sev: add SEV-SNP feature detection/setup Brijesh Singh
2022-01-25 18:43 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 35/40] x86/sev: use firmware-validated CPUID for SEV-SNP guests Brijesh Singh
2022-01-26 18:35 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 36/40] x86/sev: Provide support for SNP guest request NAEs Brijesh Singh
2022-01-27 16:21 ` Borislav Petkov
2022-01-27 17:02 ` Brijesh Singh
2022-01-29 10:27 ` Borislav Petkov
2022-01-29 11:49 ` Brijesh Singh
2022-01-29 12:02 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 37/40] x86/sev: Register SNP guest request platform device Brijesh Singh
2021-12-10 15:43 ` [PATCH v8 38/40] virt: Add SEV-SNP guest driver Brijesh Singh
2021-12-10 15:43 ` [PATCH v8 39/40] virt: sevguest: Add support to derive key Brijesh Singh
2021-12-10 22:27 ` Liam Merwick
2021-12-10 15:43 ` [PATCH v8 40/40] virt: sevguest: Add support to get extended report Brijesh Singh
2021-12-10 20:17 ` [PATCH v8 00/40] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Dave Hansen
2021-12-10 20:20 ` Brijesh Singh
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=20220127172308.erfrpuwm6ivbdh5q@amd.com \
--to=michael.roth@amd.com \
--cc=ak@linux.intel.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=dgilbert@redhat.com \
--cc=dovmurik@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=jroedel@suse.de \
--cc=kirill@shutemov.name \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=marcorr@google.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pgonda@google.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rientjes@google.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=slp@redhat.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tobin@ibm.com \
--cc=tony.luck@intel.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).