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&data=04%7C01%7Cmichael.roth%40amd.com%7Cd913249cd25d44e389d108d9370f40ab%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637601360942853147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ghw22DdACcxZsfaWd%2FyAuhlr4NwJY8b63bXPvB1MvTY%3D&reserved=0
