Hi Arthur, The master header is a legacy thing and I'm in favor of removing it. That said, as you and Michal mentioned, there's some work to do first. I started https://ticket.coreboot.org/issues/306 to help track what's missing.
Patrick Am Mi., 28. Apr. 2021 um 08:42 Uhr schrieb Arthur Heymans < art...@aheymans.xyz>: > Hi > > Currently the "COREBOOT" FMAP cbfs region has a file named "cbfs master > header" at the bottom of this fmap region and the X86 bootblock has a > pointer at 0xFFFFFFFC to it. Other ARCH have a "header pointer" file at the > top of that FMAP region pointing to it. > > Currently this file is only used as an anchor point to use cbfs with > walkcbfs_asm on X86 to access cbfs in assembly (before any C code). There > are 2 uses for this at the moment: > 1) updating microcode on Intel systems that don't feature FIT before > setting up CAR > 2) finding FSP-T (if FSP_CAR is used) before jumping to it > Both the cbfstool and the C coreboot code don't rely on it anymore, so it > is a legacy feature. Other cbfs FMAP region like FW_MAIN_A/B in a VBOOT > setup don't feature it. > > Accessing cbfs with walkcbfs_asm breaks hardware based root of trust > security mechanisms like Intel bootguard/TXT/CBnT, because no verification > or measurement whatsoever happens on either " cbfs master header" of > "fsp-t" files. So for instance even if TXT/Bootguard measured or verified > FSP-T as an IBB so that it is trusted, an attacker could insert a new cbfs > file with the same name, "fsp-t" at a lower address and coreboot will run > it anyway. So a static pointer to fsp-t is required. Sidenote/Rant: FSP-T > continuously causes such integration problems... Blobs that set up the > execution environment are just a very bad idea. > > So I propose to drop the legacy "cbfs master header" file and adapt the 2 > current use cases in the following way: > - Reuse the Intel FIT table and implement FIT microcode updates in > assembly/software. (I had this working on some point, before I decided to > use walkcbfs_asm) > - Either fix the location of FSP-T via for instance a Kconfig option or > add a pointer to "fsp-t" at a fixed location in the bootblock and have the > tooling update the pointer during the build process. I think the Kconfig > option is the least amount of work and cbfstool is already overloaded with > options and flags, so my preference goes to this. > > Let me know what you think. > > Kind regards > > Arthur Heymans > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
