coreboot implementation for AMD

[krystian-hebel]

This task will implement support for performing DRTM between coreboot and its payload, in this case edk2. While the implementation of dynamic launch will be in coreboot, the payload must be able to handle unusual state after the hand-off. It also has to carefully manage the access to memory, as well as control when and how other cores are allowed to be started. Finally, the payload binary must contain information that would tell coreboot that it can be started through dynamic launch.

The implementation may reuse parts of PoC.

• AMD only, but cpu/amd/pi isn't proper place for this code
• Many commits were added just for edk2 payload (at least all with SMM in the name), those should be present in Dasharo already so they don't have to be ported
• SKL revision wasn't specified in the config, default branch was always used. This must be changed to have reproducible builds
• SLRT needs to be added, old code uses SKL tags
• PoC TODOs: include headers directly from SKL, 64b (optional?), reserve space for TPM event log
• Documentation in coreboot: description of new option, use cases, supported/tested families and payload requirements (common and AMD-specific)
• If Dasharo gains support for newer AMD platforms: changes required for PSP involvement in SKINIT - discovery, implementation and documentation
• Send patches to upstream coreboot

Form: PR to https://github.com/Dasharo/coreboot, and if needed also https://github.com/TrenchBoot/secure-kernel-loader
Proof: logs from debug version of SKL

[SergiiDmytruk]

Possible implementation sequence:

1. Read specification at https://trenchboot.org/specifications/Secure_Launch/ (it's being updated in specification: updating for latest linux changes documentation#35, but may stick with the older version first and update it later, the changes are significant only for UEFI and they don't really apply in this case).
2. Look through the PoC and rebase/cherry-pick it onto latest Dasharo coreboot. Problematic things can be left out or commented out. Just figure out how things relate to each other in the sources. Make the firmware build.
3. Go through the list of code changes mentioned above. Configuration updates could be done first (help can be left as TODOs) to use conditional compilation in the code where needed later. Then switch to SLRT updates (it's derived from SKL tags, so not a massive rewrite), handle TPM log.
4. At this point testing should be possible. SKL could be made to print a message and hang as there are no EDK part yet.
5. Now can fill in help, documentation and make commits look pretty for upstream (see).
6. Upstreaming should wait (could be posted as WIP first) until EDK actually works to not fix up things later.

If the whole DRTM process isn't clear, starting with documentation may be a good idea to sort it out first.

[hanetzer]

Hello. Yeah, that was my general game plan, with some variations. the hardware boots and I'm installing arch on an internal drive right now to make the process a little easier.

[hanetzer]

Building the i386 toolchain on my system breaks during configure for gmp. mainline coreboot builds the toolchain (and rom) just fine, so I think I'm 'too updated' to build on my main system. can't even get to coreboot.rom. What build env is 'expected' for dasharo's fork of coreboot?

Edit: matrix space pointed me at the docker and some other minor stuff. All good now.