Drtm payload 25.12

[hanetzer]

Replacement of #916, can't change my branch, just the target. Hoping to avoid losing the comments there. Sorry for the noise.

[SergiiDmytruk]

Reviewed the changes in more detail.

[hanetzer]

I think one problem I'm really having is mapping secure-launch terminology to coreboot parts. This is outside my normal area of 'doing coreboot' stuff, I'd much rather and be more in my comfort zone porting new platforms but I'll take what I can get. If you could explain, for example, what part of this stack maps to DLME, for example, I'd probably have an easier time of it moving forward.

[SergiiDmytruk]

I think one problem I'm really having is mapping secure-launch terminology to coreboot parts. This is outside my normal area of 'doing coreboot' stuff, I'd much rather and be more in my comfort zone porting new platforms but I'll take what I can get. If you could explain, for example, what part of this stack maps to DLME, for example, I'd probably have an easier time of it moving forward.

Just saw this comment and I think you figured it out by now, but anyway:

• DCE preamble is coreboot
• DL Event is SKINIT instruction or rather its handler in CPU/PSP
• DCE is SKL
• DLME is EDK2 and by extension whatever it runs (which is the purpose of putting DRTM in the firmware)

[hanetzer]

Just saw this comment and I think you figured it out by now, but anyway:

• DCE preamble is coreboot
• DL Event is SKINIT instruction or rather its handler in CPU/PSP
• DCE is SKL
• DLME is EDK2 and by extension whatever it runs (which is the purpose of putting DRTM in the firmware)

Thank you. I'm honestly crap with terminology at times so having a definitive 'this is that' list helps. I guess if edk2 loads grub, grub also goes onto the dlme listing? and also later the kernel?

[SergiiDmytruk]

I guess if edk2 loads grub, grub also goes onto the dlme listing? and also later the kernel?

Yes, although it makes sense to start Linux directly by the firmware in this scenario to execute less code in the early boot environment (Secure Boot could validate GRUB and it has lockdown mode, but there is still a lot of code in there).

[SergiiDmytruk]

This event log is for SRTM. DRTM's measurements form an independent chain that can also be reset if DRTM is re-started, so the log needs to be separate (cbmem_add()).

[hanetzer]

hmm. Would I need to define a new CBMEM_ID then? CBMEM_ID_SRTM_LOG or so?

[SergiiDmytruk]

hmm. Would I need to define a new CBMEM_ID then?

Yes, I think cbmem_add() requires it. Updating https://github.com/Dasharo/coreboot/blob/dasharo/src/commonlib/bsd/include/commonlib/bsd/cbmem_id.h is two places should be enough.

CBMEM_ID_SRTM_LOG or so?

"DRTM", maybe CBMEM_ID_TPM_DRTM_LOG to be less ambiguous.

[SergiiDmytruk]

// TODO: Support 1.2?

coreboot, SKL and EDK support TPM1.2 and the cost for it here is a bit of initialization (see it in GRUB; despite the name that function is used on AMD as well), so may as well do it. TPM2.0 log just needs to be zeroed, its size in GRUB is 32 KiB regardless of TPM family.