[M] Change in coreboot[main]: cpu/x86: Support SMBASE relocation-only use-case

[Benjamin Doron (Code Review)]

Attention is currently required from: Angel Pons, Dinesh Gehlot, Eran Mitrani, Felix Held, Fred Reitberger, Jason Glenesk, Kapil Porwal, Martin L Roth, Matt DeVillier, Matt DeVillier, Maulik Vaghela, Raul Rangel, Subrata Banik, Tarun, Tarun Tuli, ron minnich.

Benjamin Doron has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/70376?usp=email )

Change subject: cpu/x86: Support SMBASE relocation-only use-case
......................................................................

Patch Set 7:

(3 comments)

Patchset:

PS7:
> i'm a bit concerned if this approach has any security implications; moving away from coreboot only i […]

It's a fair concern, but if we want to use payload SMI handlers, the payload must put code in SMM. Yes, this puts the payload in the TCB/a more privileged position than before, though the user should be allowed to make that trade-off.

It's not a 'true' HOB (that is, in ring-0 memory that's created by PEI and available to DXE). When this design was first created for SBL + EDK2, they reused the HOB data struct, but it's just a single struct at the start of SMRAM. It's created by SMM code, then locked, then (SMRAM is) available again to the bootloader on an S3 resume.

File src/cpu/x86/Kconfig:

https://review.coreboot.org/c/coreboot/+/70376/comment/57c827a6_208360ad :
PS7, Line 159: 	bool
             : 	default n
> I don't see this Kconfig option being used in this patch. […]

It's used above by HAVE_NATIVE_SMI_HANDLER, which determines if smm.manual ("permanent handlers") is linked in, among other things. This Kconfig can be used to disable that one. If by 'not being used' you mean that it has no effect, well, we could remove it, but I think that would leave this setup/patch incomplete.

File src/southbridge/intel/common/Kconfig.common:

https://review.coreboot.org/c/coreboot/+/70376/comment/0debe57d_ff9c1913 :
PS7, Line 93: HAVE_SMI_HANDLER
> 2nd

Ah, because from memory, this would leave SPI, etc. unlocked for the external SMM case, and it's safe to drop because apmc_trigger won't actually initiate the SMI. This will leave specific parts of lockdown incomplete, I'll check whether they're necessary (we actually want SMRAM unlocked so that the payload can use it).

The point is to get as much lockdown done here as possible.