linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Michael Roth <michael.roth@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Kuppuswamy,
	Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	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, linux-crypto@vger.kernel.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>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	Andy Lutomirski <luto@kernel.org>, 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>,
	tony.luck@intel.com, npmccallum@redhat.com
Subject: Re: [PATCH Part1 RFC v3 20/22] x86/boot: Add Confidential Computing address to setup_header
Date: Thu, 24 Jun 2021 09:11:11 -0500	[thread overview]
Message-ID: <20210624141111.pzvb6gk5lzfelx26@amd.com> (raw)
In-Reply-To: <YNSAlJnXMjigpqu1@zn.tnic>

On Thu, Jun 24, 2021 at 02:54:44PM +0200, Borislav Petkov wrote:
> On Thu, Jun 24, 2021 at 07:34:47AM -0500, Michael Roth wrote:
> > Well, that's sufficient for the boot/compressed->uncompressed parameter
> > passing, but wouldn't actual bootloaders still need something in
> > setup_data/setup_header to pass in the CC blob (for things like non-EFI
> > environments/containers)? I was under the impression that using
> > boot_params directly was more of a legacy/ad-hoc thing, is that
> > accurate?
> 
> /me goes and rereads your early mail.
> 
> I'm more confused.

Sorry for the confusion, hopefully I can explain better now that I've
had some coffee.

> 
> You're talking about parsing an EFI table early which contains the
> ccblob and in it is the CPUID page.
> 
> Now above you say, "non-EFI environments".
> 
> I'm guessing you want to support both so you want to either parse an EFI
> table on EFI environments or pass the blob in a different way in non-EFI
> envs. Yes, no?

Yes.

> 
> Also, you want to pass the previously parsed CPUID page address to
> kernel proper. For that I suggested to use boot_params.

Yes. (though I'm actually passing the whole CC blob address so kernel
proper can get the CPUID address from there. That gives us the option of
using that field to get at the secret page in very early boot of
uncompressed/proper kernel as well).

> 
> What else?
> 
> How about you explain in a lot more detail what exactly the requirements
> and the use cases are so that we can have a common base to discuss it
> on.

So for EFI case:

  We don't need anything in setup_data/setup_header. We can access the
  CC blob table via EFI config table. However, parsing EFI config table
  early in uncompressed/proper kernel has the complications I mentioned in my
  initial response. This is where using a new boot_params field comes into
  play (similar to acpi_rsdp_addr), so boot/compressed can pass
  uncompressed/proper kernel a pointer to the pre-parsed CC blob so it doesn't
  need to re-parse EFI config table during early boot.

For non-EFI case:

  We need a "proper" mechanism that bootloaders can use. My
  understanding is this would generally be via setup_data or
  setup_header, and that a direct boot_params field would be frowned
  upon.

So your understanding of the situation seems correct.

By bringing up the non-EFI case I only meant to point out that by using a
field in setup_header, we could re-use that field for the EFI case as well,
and wouldn't need a seperate boot_params field to handle the
boot/compressed->uncompressed passing of the pre-parsed CC blob address
in the EFI case. But I don't think it makes a big difference as far as
my stuff goes at least. Maybe for TDX though this needs more thought.

> 
> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&amp;data=04%7C01%7Cmichael.roth%40amd.com%7Cd913249cd25d44e389d108d9370f40ab%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637601360942853147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ghw22DdACcxZsfaWd%2FyAuhlr4NwJY8b63bXPvB1MvTY%3D&amp;reserved=0

  reply	other threads:[~2021-06-24 14:11 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 14:03 [PATCH Part1 RFC v3 00/22] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Brijesh Singh
2021-06-02 14:03 ` [PATCH Part1 RFC v3 01/22] x86/sev: shorten GHCB terminate macro names Brijesh Singh
2021-06-08 15:54   ` Venu Busireddy
2021-06-02 14:03 ` [PATCH Part1 RFC v3 02/22] x86/sev: Define the Linux specific guest termination reasons Brijesh Singh
2021-06-08 15:59   ` Venu Busireddy
2021-06-08 16:51     ` Brijesh Singh
2021-06-02 14:03 ` [PATCH Part1 RFC v3 03/22] x86/sev: Save the negotiated GHCB version Brijesh Singh
2021-06-03 19:57   ` Borislav Petkov
2021-06-08 17:35   ` Venu Busireddy
2021-06-02 14:03 ` [PATCH Part1 RFC v3 04/22] x86/mm: Add sev_feature_enabled() helper Brijesh Singh
2021-06-05 10:50   ` Borislav Petkov
2021-06-02 14:03 ` [PATCH Part1 RFC v3 05/22] x86/sev: Add support for hypervisor feature VMGEXIT Brijesh Singh
2021-06-07 14:19   ` Borislav Petkov
2021-06-07 14:58     ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 06/22] x86/sev: check SEV-SNP features support Brijesh Singh
2021-06-07 14:54   ` Borislav Petkov
2021-06-07 16:01     ` Brijesh Singh
2021-06-17 18:46     ` Brijesh Singh
2021-06-18  5:46       ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 07/22] x86/sev: Add a helper for the PVALIDATE instruction Brijesh Singh
2021-06-07 15:35   ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 08/22] x86/compressed: Add helper for validating pages in the decompression stage Brijesh Singh
2021-06-08 11:12   ` Borislav Petkov
2021-06-08 15:58     ` Brijesh Singh
2021-06-16 10:21   ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 09/22] x86/compressed: Register GHCB memory when SEV-SNP is active Brijesh Singh
2021-06-09 17:47   ` Borislav Petkov
2021-06-14 12:28     ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 10/22] x86/sev: " Brijesh Singh
2021-06-10  5:49   ` Borislav Petkov
2021-06-14 12:29     ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 11/22] x86/sev: Add helper for validating pages in early enc attribute changes Brijesh Singh
2021-06-10 15:50   ` Borislav Petkov
2021-06-14 12:45     ` Brijesh Singh
2021-06-14 19:03       ` Borislav Petkov
2021-06-14 21:01         ` Brijesh Singh
2021-06-16 10:07           ` Borislav Petkov
2021-06-16 11:00             ` Brijesh Singh
2021-06-16 12:03               ` Borislav Petkov
2021-06-16 12:49                 ` Brijesh Singh
2021-06-16 13:02                   ` Borislav Petkov
2021-06-16 13:10                     ` Brijesh Singh
2021-06-16 14:36                       ` Brijesh Singh
2021-06-16 14:37                         ` Brijesh Singh
2021-06-16 13:06                   ` Dr. David Alan Gilbert
2021-06-02 14:04 ` [PATCH Part1 RFC v3 12/22] x86/kernel: Make the bss.decrypted section shared in RMP table Brijesh Singh
2021-06-10 16:06   ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 13/22] x86/kernel: Validate rom memory before accessing when SEV-SNP is active Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 14/22] x86/mm: Add support to validate memory when changing C-bit Brijesh Singh
2021-06-11  9:44   ` Borislav Petkov
2021-06-14 13:05     ` Brijesh Singh
2021-06-14 19:27       ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 15/22] KVM: SVM: define new SEV_FEATURES field in the VMCB Save State Area Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 16/22] KVM: SVM: Create a separate mapping for the SEV-ES save area Brijesh Singh
2021-06-14 10:58   ` Borislav Petkov
2021-06-14 19:34     ` Tom Lendacky
2021-06-14 19:50       ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 17/22] KVM: SVM: Create a separate mapping for the GHCB " Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 18/22] KVM: SVM: Update the SEV-ES save area mapping Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 19/22] x86/sev-snp: SEV-SNP AP creation support Brijesh Singh
2021-06-16 13:07   ` Borislav Petkov
2021-06-16 16:13     ` Tom Lendacky
2021-06-02 14:04 ` [PATCH Part1 RFC v3 20/22] x86/boot: Add Confidential Computing address to setup_header Brijesh Singh
2021-06-18  6:08   ` Borislav Petkov
2021-06-18 13:57     ` Brijesh Singh
2021-06-18 15:05       ` Borislav Petkov
2021-06-23  4:30         ` Michael Roth
2021-06-23 10:22           ` Borislav Petkov
2021-06-24  3:19             ` Michael Roth
2021-06-24  7:27               ` Borislav Petkov
2021-06-24 12:26                 ` Michael Roth
2021-06-24 12:34                 ` Michael Roth
2021-06-24 12:54                   ` Borislav Petkov
2021-06-24 14:11                     ` Michael Roth [this message]
2021-06-25 14:48                       ` Borislav Petkov
2021-06-25 15:24                         ` Brijesh Singh
2021-06-25 17:01                           ` Borislav Petkov
2021-06-25 18:14                             ` Michael Roth
2021-06-28 13:43                               ` Borislav Petkov
2021-06-24 13:09               ` Kuppuswamy, Sathyanarayanan
2021-06-02 14:04 ` [PATCH Part1 RFC v3 21/22] x86/sev: Register SNP guest request platform device Brijesh Singh
2021-06-04 11:28   ` Sergio Lopez
2021-06-09 19:24   ` Dr. David Alan Gilbert
2021-06-11 13:16     ` Tom Lendacky
2021-06-14 17:15       ` Dr. David Alan Gilbert
2021-06-14 18:24         ` Brijesh Singh
2021-06-14 13:20     ` Brijesh Singh
2021-06-14 17:23       ` Dr. David Alan Gilbert
2021-06-14 20:50         ` Brijesh Singh
2021-06-18  9:46   ` Borislav Petkov
2021-06-18 13:59     ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest driver Brijesh Singh
2021-06-30 13:35   ` Borislav Petkov
2021-06-30 16:26     ` Brijesh Singh
2021-07-01 18:03       ` Borislav Petkov
2021-07-01 21:32         ` Brijesh Singh
2021-07-03 16:19           ` Borislav Petkov
2021-07-05 10:39             ` Brijesh Singh
2021-06-07 19:15 ` [PATCH Part1 RFC v3 00/22] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Venu Busireddy
2021-06-07 19:17   ` Borislav Petkov

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=20210624141111.pzvb6gk5lzfelx26@amd.com \
    --to=michael.roth@amd.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=jroedel@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=npmccallum@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=tony.luck@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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).