[coreboot] Dropping the "cbfs master header" file

[Arthur Heymans]

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