bzImage size issue while porting to new board

Hi, i hope this is the right place to ask. I'm in the process of "porting" heads to FW4B. The board actually seems to be sold under a lot of names e.g. in germany by thomas krenn as LES compact 4L but in coreboot its called FW4B so lets stick with that. It has an 8MB flash chip and brasswell generation CPU so took the x220 config as a starting point for heads. So far so good, but when it comes to packing the payload into coreboot i run into:

E: Could not add [../../build/FW4B/bzImage, 7141808 bytes (6974 KB)@0x0]; too big?
E: Failed to add '../../build/FW4B/bzImage' into ROM image.
E: Failed while operating on 'COREBOOT' region!
E: The image will be left unmodified.

i'm a bit lost here where to look for shrinking the kernel as the config seems to work for the x220 with the same flash size. I guess i missed something regarding the CBFS size or ME cleaning??

Hi, i hope this is the right place to ask.

Indeed! Welcome aboard @derpeter!

I'm in the process of "porting" heads to FW4B. The board actually seems to be sold under a lot of names e.g. in germany by thomas krenn as LES compact 4L but in coreboot its called FW4B so lets stick with that. It has an 8MB flash chip and brasswell generation CPU so took the x220 config as a starting point for heads. So far so good, but when it comes to packing the payload into coreboot i run into:
E: Could not add [../../build/FW4B/bzImage, 7141808 bytes (6974 KB)@0x0]; too big?
E: Failed to add '../../build/FW4B/bzImage' into ROM image.
E: Failed while operating on 'COREBOOT' region!
E: The image will be left unmodified.
i'm a bit lost here where to look for shrinking the kernel as the config seems to work for the x220 with the same flash size. I guess i missed something regarding the CBFS size or ME cleaning??

8mb is tight.

Ok. You are trying to put bigger things in then the x220, i'm not aware of what FW4B is packing up more as requirements there. ME cleaner output would be great, since the size output there would permit to understand what is the CBFS_REGION adjustments that should happen there, considering that you output a valid IFD, that the regions outputted there are right.

CPU being Broadwell?

So similar ME neutered size is expected https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F#me-versions-from-60-nehalem-to-10x-broadwell-1
This will tell us the truth: https://github.com/corna/me_cleaner/wiki/External-flashing#neutralize-and-shrink-intel-me-useful-only-for-coreboot

Ok. You are trying to put bigger things in then the x220, i'm not aware of what FW4B is packing up more as requirements there. ME cleaner output would be great, since the size output there would permit to understand what is the CBFS_REGION adjustments that should happen there, considering that you output a valid IFD, that the regions outputted there are right.

as i used the linux config from x230 which is also used for x220 i'm confused why its getting bigger, as fahr as i understand the reproducible build approach in heads it should create the same binary more or less, right?

CPU being Broadwell?

no its brasswell, Celeron J3160

So similar ME neutered size is expected https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F#me-versions-from-60-nehalem-to-10x-broadwell-1

This will tell us the truth: https://github.com/corna/me_cleaner/wiki/External-flashing#neutralize-and-shrink-intel-me-useful-only-for-coreboot

Thanks for the quick response, i will check the ME output tomorrow when i have access to the device again.

You are doing x220 board vs x220-maximized as a base?

Since x220 cannot be tested from CircleCI it is possible that that board simply doesn't build anymore :/

I have checked the coreboot config for both files, and it would widely depend if the blobs are automatically generated (blobs/xx20 scripts) or if ME was only partially deactivated and not neutered and reduced, as made for maximized boards.

If ME is neutered, ME would take less then x230 maximized 98k, ifd would fit and x220-maximized build output on CircleCI for board step would give you insights on what is happening.

https://app.circleci.com/pipelines/github/osresearch/heads/395/workflows/d3cb9183-849c-467a-8057-0d0a291a7d6e/jobs/2709/parallel-runs/0/steps/0-103

excerpt:

# Use coreboot.rom, because custom output files might not be processed by cbfstool
"/root/project/build/coreboot-4.13/x220-maximized/cbfstool" "/root/project/build/coreboot-4.13/x220-maximized/coreboot.rom" print
FMAP REGION: COREBOOT
Name                           Offset     Type           Size   Comp
cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           84972 none
cpu_microcode_blob.bin         0x14d00    microcode       26624 none
fallback/ramstage              0x1b580    stage           97632 none
config                         0x33340    raw               776 none
revision                       0x33680    raw               691 none
fallback/dsdt.aml              0x33980    raw             14615 none
vbt.bin                        0x37300    raw              1400 LZMA (3985 decompressed)
cmos_layout.bin                0x378c0    cmos_layout      1848 none
fallback/postcar               0x38040    stage           25816 none
fallback/payload               0x3e580    simple elf    7199175 none
(empty)                        0x71bf80   null            81432 none
bootblock                      0x72fdc0   bootblock       65536 none

So here, you can see that the payload: initrd (containing heads.cpio, tools.cpio, modules.cpio) and the kernel (your bzImage).

The build trace (when make BOARD=xyz V=1 to enable verbose output on screen, so equivalent of what you can find here, for the full board build step over CircleCI

This is how built parts are added into coreboot:

Created CBFS (capacity = 7601624 bytes)
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add \
    -f x220-maximized/cbfs/fallback/bootblock.bin \
    -n bootblock \
    -t bootblock \
     \
     \
    -b -65536  \

x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-master-header 
printf "    CBFS       fallback/romstage\n"
    CBFS       fallback/romstage
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-stage -f x220-maximized/cbfs/fallback/romstage.elf -n fallback/romstage  -c none  -r COREBOOT -a 64 -S ".car.data" --xip
printf "    CBFS       cpu_microcode_blob.bin\n"
    CBFS       cpu_microcode_blob.bin
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/cpu_microcode_blob.bin -n cpu_microcode_blob.bin -t microcode   -r COREBOOT -a 16 
printf "    CBFS       fallback/ramstage\n"
    CBFS       fallback/ramstage
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-stage -f x220-maximized/cbfs/fallback/ramstage.elf -n fallback/ramstage  -c LZMA  -r COREBOOT   
printf "    CBFS       config\n"
    CBFS       config
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/mainboard/lenovo/x220/cbfs-file.EUvgZy.out -n config -t raw   -r COREBOOT   
printf "    CBFS       revision\n"
    CBFS       revision
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/build.h -n revision -t raw   -r COREBOOT   
printf "    CBFS       fallback/dsdt.aml\n"
    CBFS       fallback/dsdt.aml
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/dsdt.aml -n fallback/dsdt.aml -t raw -c none  -r COREBOOT   
printf "    CBFS       vbt.bin\n"
    CBFS       vbt.bin
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f src/mainboard/lenovo/x220/variants/x220/data.vbt -n vbt.bin -t raw -c lzma  -r COREBOOT   
printf "    CBFS       cmos_layout.bin\n"
    CBFS       cmos_layout.bin
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/cmos_layout.bin -n cmos_layout.bin -t cmos_layout   -r COREBOOT   
printf "    CBFS       fallback/postcar\n"
    CBFS       fallback/postcar
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-stage -f x220-maximized/cbfs/fallback/postcar.elf -n fallback/postcar  -c none  -r COREBOOT   
printf "    CBFS       fallback/payload\n"
    CBFS       fallback/payload
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-payload -f ../../build/x220-maximized/bzImage -n fallback/payload  -c none  -r COREBOOT   -C "intel_iommu=igfx_off quiet" -I "../../build/x220-maximized/initrd.cpio.xz"
true
mv x220-maximized/coreboot.pre.tmp x220-maximized/coreboot.pre
printf "    DD         Adding Intel Firmware Descriptor\n"
    DD         Adding Intel Firmware Descriptor
dd if="../../blobs/xx20/ifd.bin" \
    of=x220-maximized/coreboot.pre conv=notrunc >/dev/null 2>&1
printf "    IFDTOOL    me.bin -> coreboot.pre\n"
    IFDTOOL    me.bin -> coreboot.pre
x220-maximized/util/ifdtool/ifdtool \
     \
    -i ME:"../../blobs/xx20/me.bin" \
    -O x220-maximized/coreboot.pre \
    x220-maximized/coreboot.pre
File x220-maximized/coreboot.pre is 8388608 bytes
File ../../blobs/xx20/me.bin is 86016 bytes
Adding ../../blobs/xx20/me.bin as the Intel ME section of x220-maximized/coreboot.pre
Writing new image to x220-maximized/coreboot.pre
printf "    IFDTOOL    gbe.bin -> coreboot.pre\n"
    IFDTOOL    gbe.bin -> coreboot.pre
x220-maximized/util/ifdtool/ifdtool \
     \
    -i GbE:"../../blobs/xx20/gbe.bin" \
    -O x220-maximized/coreboot.pre \
    x220-maximized/coreboot.pre
File x220-maximized/coreboot.pre is 8388608 bytes
File ../../blobs/xx20/gbe.bin is 8192 bytes
Adding ../../blobs/xx20/gbe.bin as the GbE section of x220-maximized/coreboot.pre
Writing new image to x220-maximized/coreboot.pre
printf "    IFDTOOL    Unlocking Management Engine\n"
    IFDTOOL    Unlocking Management Engine
x220-maximized/util/ifdtool/ifdtool \
 -u \
-O x220-maximized/coreboot.pre \
x220-maximized/coreboot.pre
File x220-maximized/coreboot.pre is 8388608 bytes
Writing new image to x220-maximized/coreboot.pre
    CBFS       coreboot.rom
dd if=/dev/zero bs=8388608 count=1 2> /dev/null | tr '\000' '\377' > x220-maximized/coreboot.rom.tmp
dd if=x220-maximized/coreboot.pre of=x220-maximized/coreboot.rom.tmp bs=8192 conv=notrunc 2> /dev/null
mv x220-maximized/coreboot.rom.tmp x220-maximized/coreboot.rom
    CBFSLAYOUT  coreboot.rom

x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.rom layout
This image contains the following sections that can be manipulated with this tool:

'RW_MRC_CACHE' (size 65536, offset 720896)
'COREBOOT' (CBFS, size 7601664, offset 786944)

It is possible to perform either the write action or the CBFS add/remove actions on every section listed above.
To see the image's read-only sections as well, rerun with the -w option.
    CBFSPRINT  coreboot.rom

x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.rom print -r COREBOOT
FMAP REGION: COREBOOT
Name                           Offset     Type           Size   Comp
cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           84972 none
cpu_microcode_blob.bin         0x14d00    microcode       26624 none
fallback/ramstage              0x1b580    stage           97632 none
config                         0x33340    raw               776 none
revision                       0x33680    raw               691 none
fallback/dsdt.aml              0x33980    raw             14615 none
vbt.bin                        0x37300    raw              1400 LZMA (3985 decompressed)
cmos_layout.bin                0x378c0    cmos_layout      1848 none
fallback/postcar               0x38040    stage           25816 none
fallback/payload               0x3e580    simple elf    7199175 none
(empty)                        0x71bf80   null            81432 none
bootblock                      0x72fdc0   bootblock       65536 none
printf "\nBuilt %s (%s)\n" lenovo/x220 \
    "ThinkPad X220"

Of course, the pre-requisites to build this is to run the blobs/xx20/download_parse_me.sh, which downloads firmware from Lenovo, clean me and dump it under me.bin. The gbe.bin and ifd.bin is taken from blobs/xx20/ directory from the corresponding coreboot-x220-maximized.config.

If you are taking the x20 board as a reference, the correspondoing coreboot-x220.config file is taking its blobs from blobs/x220/ directory, where extract.sh is calling a standard (not customized) me_cleaner call, which is not neutering anything, not removing the blobs. Consequently, it is kinda impossible that the x220 board (as opposed to x20-maximized) is building as we speak. The fact that x220 owners are not opening issues tend to say they continue to use older versions of their ROM.

I suspect some issues will start opening soon, since x220-maximized doesn't currently have enough ROM storage to include cryptsetup2 as we speak. So users migrating to newer OSes, requiring cryptsetup2, and users relying on TPM Disk Unlock Keys will start to complain soon.

Short version: You should check against x220-maximized board, not x220.

Questions around FW4B (for lazy web. Too lazy to search for it after having read Celeron)

It has TPM?
The SPI cannot be changed easily? (is there different config options for ROM size under coreboot configurator?) How hard to change that? (KGPE-D16 is removable, as is the KCM-D8 and a alot of other boards...)
Does it have virtualization extensions ? Would it support Qubes OS (vt-x, vt-d support)?

Another note about blobs/x220/extract: $MECLEAN -O "$BLOBDIR/me.bin" -r -t "$extractdir/flashregion_2_intel_me.bin"

is calling different options then: $ python me_cleaner.py -S -r -t -d -O out.bin -D ifd_shrinked.bin -M me_shrinked.bin original_dump.bin

Where

-r, --relocate        relocate the FTPR partition to the top of the ME
                        region to save even more space
-t, --truncate        truncate the empty part of the firmware (requires a
                        separated ME/TXE image or --extract-me)

Is nowhere changing the ifd descriptor so it can make more space available for the BIOS region, but yo uare not reaching that point, which from given log above, will fail right after.

  -d, --descriptor      remove the ME/TXE Read/Write permissions to the other
                        regions on the flash from the Intel Flash Descriptor
                        (requires a full dump)
  -S, --soft-disable    in addition to the usual operations on the ME/TXE
                        firmware, set the MeAltDisable bit or the HAP bit to
                        ask Intel ME/TXE to disable itself after the hardware
                        initialization (requires a full dump)
  -D output_descriptor, --extract-descriptor output_descriptor
                        extract the flash descriptor from a full dump; when
                        used with --truncate save a descriptor with adjusted
                        regions start and end
  -M output_me_image, --extract-me output_me_image
                        extract the ME firmware from a full dump; when used
                        with --truncate save a truncated ME/TXE image

coreboot: There are a lot at play here. Heads store its configs in savedefconfig format. You might want to copy that coreboot config into extracted build/coreboot-4.13/.config and go into that dir and do a make menuconfig, and then look at the expended config that you can see there. I am pretty sure that the defaults for your board also include maybe libgfx, debug, making coreboot bigger and making the coreboot assembly of the firmware fail.

Lets remember that all the following were already assembled if you fail at bzImage:

Created CBFS (capacity = 7601624 bytes)
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add \
    -f x220-maximized/cbfs/fallback/bootblock.bin \
    -n bootblock \
    -t bootblock \
     \
     \
    -b -65536  \

x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-master-header 
printf "    CBFS       fallback/romstage\n"
    CBFS       fallback/romstage
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-stage -f x220-maximized/cbfs/fallback/romstage.elf -n fallback/romstage  -c none  -r COREBOOT -a 64 -S ".car.data" --xip
printf "    CBFS       cpu_microcode_blob.bin\n"
    CBFS       cpu_microcode_blob.bin
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/cpu_microcode_blob.bin -n cpu_microcode_blob.bin -t microcode   -r COREBOOT -a 16 
printf "    CBFS       fallback/ramstage\n"
    CBFS       fallback/ramstage
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-stage -f x220-maximized/cbfs/fallback/ramstage.elf -n fallback/ramstage  -c LZMA  -r COREBOOT   
printf "    CBFS       config\n"
    CBFS       config
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/mainboard/lenovo/x220/cbfs-file.EUvgZy.out -n config -t raw   -r COREBOOT   
printf "    CBFS       revision\n"
    CBFS       revision
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/build.h -n revision -t raw   -r COREBOOT   
printf "    CBFS       fallback/dsdt.aml\n"
    CBFS       fallback/dsdt.aml
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/dsdt.aml -n fallback/dsdt.aml -t raw -c none  -r COREBOOT   
printf "    CBFS       vbt.bin\n"
    CBFS       vbt.bin
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f src/mainboard/lenovo/x220/variants/x220/data.vbt -n vbt.bin -t raw -c lzma  -r COREBOOT   
printf "    CBFS       cmos_layout.bin\n"
    CBFS       cmos_layout.bin
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add -f x220-maximized/cmos_layout.bin -n cmos_layout.bin -t cmos_layout   -r COREBOOT   
printf "    CBFS       fallback/postcar\n"
    CBFS       fallback/postcar
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-stage -f x220-maximized/cbfs/fallback/postcar.elf -n fallback/postcar  -c none  -r COREBOOT   
printf "    CBFS       fallback/payload\n"
    CBFS       fallback/payload
x220-maximized/util/cbfstool/cbfstool x220-maximized/coreboot.pre.tmp add-payload -f ../../build/x220-maximized/bzImage -n fallback/payload  -c none  -r COREBOOT   -C "intel_iommu=igfx_off quiet" -I "../../build/x220-maximized/initrd.cpio.xz"
true

Basically, everything coreboot was assembled when bzImage is added (which includes also the compressed initrd!)

More logs would be welcome. Otherwise, this is the best I can do. And answers on if that would be interesting for the community as well.

wow thank so much for all the infos, it will take a while to get all in my head(s) ;-).

I should have been more precise. I used the x220 linux config and based my board config on it. I did not use the x220 coreboot config but started from scratch with the default config for that board. The main change i did here is to allow native graphic init and tried bigger cbfs size. I'm wondering if not including the microcode update would also help to save some space.

The CPU support VT-x but no VT-d, i'm not familiar enough with qubes to tell if it makes sense to run it without that. Here is the full list of Flags:

Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_kno
                                 wn_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida
                                  arat md_clear

Regarding TPM the kernel tells me

[    2.134380] ima: No TPM chip found, activating TPM-bypass!

Is this a road blocker for heads? I will open the device later an look for a TPM header.

first things first: Here is the ME cleaner output:

Full image detected
Found FPT header at 0x1010
Found 20 partition(s)
Found FTPR header: FTPR partition spans from 0x6f000 to 0xe7000
ME/TXE firmware version 2.0.2.2092 (generation 2)
Public key match: Intel TXE, firmware versions 2.x.x.x
The AltMeDisable bit is NOT SET
Reading partitions list...
 PSVN (0x000003c0 - 0x000000400, 0x00000040 total bytes): removed
 FOVD (0x00000400 - 0x000001000, 0x00000c00 total bytes): removed
 MDES (0x00001000 - 0x000002000, 0x00001000 total bytes): removed
 FCRS (0x00002000 - 0x000003000, 0x00001000 total bytes): removed
 EFFS (0x00003000 - 0x00006f000, 0x0006c000 total bytes): removed
 ACDS (NVRAM partition, no data, 0x00012c4c total bytes): nothing to remove
 FTPM (NVRAM partition, no data, 0x0000b256 total bytes): nothing to remove
 IPTS (NVRAM partition, no data, 0x00000069 total bytes): nothing to remove
 ISHD (NVRAM partition, no data, 0x0000de80 total bytes): nothing to remove
 LPBK (NVRAM partition, no data, 0x0000095a total bytes): nothing to remove
 NVCL (NVRAM partition, no data, 0x00006ad2 total bytes): nothing to remove
 NVCP (NVRAM partition, no data, 0x0000ad26 total bytes): nothing to remove
 NVJC (NVRAM partition, no data, 0x00005000 total bytes): nothing to remove
 NVKR (NVRAM partition, no data, 0x00007885 total bytes): nothing to remove
 NVNF (NVRAM partition, no data, 0x00001996 total bytes): nothing to remove
 NVSL (NVRAM partition, no data, 0x00003918 total bytes): nothing to remove
 NVTD (NVRAM partition, no data, 0x000021b2 total bytes): nothing to remove
 STOK (NVRAM partition, no data, 0x000004a4 total bytes): nothing to remove
 FTPR (0x0006f000 - 0x0000e7000, 0x00078000 total bytes): NOT removed
 NFTP (0x000e7000 - 0x00015f000, 0x00078000 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0xe4)...
Reading FTPR modules list...
 BUP              (uncomp., 0x070000 - 0x088000       ): NOT removed, essential
 KERNEL           (LZMA   , 0x088000 - 0x09e4c9       ): removed
 POLICY           (LZMA   , 0x09f000 - 0x0a97c9       ): removed
 HOSTCOMM         (LZMA   , 0x0aa000 - 0x0b2daf       ): removed
 FPF              (LZMA   , 0x0b3000 - 0x0b5c68       ): removed
 RSA              (LZMA   , 0x0b6000 - 0x0bc55a       ): removed
 fTPM             (LZMA   , 0x0bd000 - 0x0cfd68       ): removed
 SBOOT            (LZMA   , 0x0d0000 - 0x0d4842       ): removed
 NFC              (LZMA   , 0x0d5000 - 0x0d875c       ): removed
 ACDS             (LZMA   , 0x0d9000 - 0x0da509       ): removed
 AFWS             (LZMA   , 0x0db000 - 0x0dc304       ): removed
The ME minimum size should be 577536 bytes (0x8d000 bytes)
The ME region can be reduced up to:
 00001000:0008dfff me
Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME...
Checking the FTPR RSA signature... VALID
Done! Good luck!

also maybe usefull flashrom output:

flashrom v1.2 on Linux 5.4.0-100-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found chipset "Intel Braswell".
Enabling flash write... OK.
Found Macronix flash chip "MX25U6435E/F" (8192 kB, SPI) mapped at physical address 0x00000000ff800000.
Reading flash... done.

I was able to read the flash and write my coreboot image with the -p internal without any problems so i assume that means we don't have any masked regions here.

I followed your advice to make coreboot smaler (disabled grafik init and debugging according to what was done on the x220) and also neutralized and shrinked ME and IFD. For some reasons this resulted in coreboot not building anymore with include issues regarding vboot seems to be related to https://www.mail-archive.com/coreboot@coreboot.org/msg55677.html i added vboot to the mainboard config of coreboot. I'm actually confused if vboot is needed for heads or if i just make the linker happy here and if i may should have taken an different approach. Never the less this seems to bring me further in build process but eventually also failed.

''' Linking out/rom32seg.o /home/peter/src/heads/build/coreboot-4.15/util/crossgcc/xgcc/bin/i386-elf-ld.bfd -T out/romlayout32seg.lds out/code32seg.o -o out/rom32seg.o Stripping out/rom32seg.noexec.o /home/peter/src/heads/build/coreboot-4.15/util/crossgcc/xgcc/bin/i386-elf-strip out/rom32seg.o -o out/rom32seg.o.strip.o Stripping out/rom16.noexec.o /home/peter/src/heads/build/coreboot-4.15/util/crossgcc/xgcc/bin/i386-elf-strip out/rom16.o -o out/rom16.o.strip.o python ./scripts/ldnoexec.py out/rom32seg.o.strip.o out/rom32seg.noexec.o python ./scripts/ldnoexec.py out/rom16.o.strip.o out/rom16.noexec.o Linking out/rom.o /home/peter/src/heads/build/coreboot-4.15/util/crossgcc/xgcc/bin/i386-elf-ld.bfd -N -T out/romlayout32flat.lds out/rom16.noexec.o out/rom32seg.noexec.o out/code32flat.o -o out/rom.o Prepping out/bios.bin.prep rm -f out/bios.bin out/Csm16.bin out/bios.bin.elf /home/peter/src/heads/build/coreboot-4.15/util/crossgcc/xgcc/bin/i386-elf-objdump -thr out/rom.o > out/rom.o.objdump /home/peter/src/heads/build/coreboot-4.15/util/crossgcc/xgcc/bin/i386-elf-objcopy -O binary out/rom.o out/bios.bin.raw python ./scripts/checkrom.py out/rom.o.objdump 0 out/bios.bin.raw out/bios.bin.prep Total size: 132768 Fixed: 72672 Free: 129376 (used 50.6% of 256KiB rom) Creating out/bios.bin.elf /home/peter/src/heads/build/coreboot-4.15/util/crossgcc/xgcc/bin/i386-elf-strip -R .comment out/rom.o -o out/bios.bin.elf rm FW4B/util/cbfstool/fmd_scanner.c FW4B/util/cbfstool/fmd_parser.c make[1]: Leaving directory '/home/peter/src/heads/build/coreboot-4.15' make: *** [Makefile:505: /home/peter/src/heads/build/coreboot-4.15/FW4B/.build] Error 1 '''

Do you got any pointers for where to proceed from here? Maybe its related to the vboot offset? I could not figure how to calculate it so i tried with the value from x220 which is probably not correct?

@derpeter Can you create a PR in draft mode or at least point to a WiP branch? Otherwise, we can only speculate and unfortunately, that wouldn't go anywhere.

@derpeter both x220 configs, being maximized or legacy, point to ifd GBE and me. They are both producing valid, fully internally/externally flashable ROMs. For the vboot part, fmd parser still needs to be happy, that is true.

From experience with other platforms like kgpe-d16, we had some issued there, but those were artifacts of using vboit+measured boot, where x220 should advise enough with its savedefconfig mode to activate TPM measured boot mode, which is not linked to vboot outside of the fmd parser.

Board config + coreboot config pointed by board config would help, and source from where to extract me and valid GBE (in your branch is fine) would help.

As you can see for x220 not maximized, the job is delegated to the user to extract blobs from a backup. If no online source exists to get the firmware image and extract things from there, that might be the only way for that board, but I have non idea.

No vt-d will not make it's way to Qubes, which is not necessarily a requirement but a thing most users here are interested.

Having a tpm is one of the basic requirement of Heads, but not a deal beaker for acceptance of a working board. I would simply have a personal difficulty pushing for that specific board.

At best, this, as other boards in PR not being merged, might not be well maintained in the future if no users are maintaining it. So this is not high priority for me, but would gladly point out to what my eyes can see.

@derpeter another pointer is that since there is no TPM, a lot of deoendencies in the board config could also be removed from the board config. https://github.com/osresearch/heads/blob/9016ebccc22eabd40245743886488cf6b89b4309/boards/x230-flash/x230-flash.config#L11

I pushed the branch https://github.com/derpeter/heads/tree/fw4b it seems this bios update https://www.thomas-krenn.com/redx/tools/mb_download.php/ct.XUkgXw/mid.yacc92cf2b3581a8a/BIOS_LEScompact4L_20190723.rar contains at least the ME.

To make sure i did not mess up something else in my heads build a started with a clean VM with a clean git clone and now run into toolchain build issues that look on the first glance like race conditions from the parallel build, i will open a new issue if it turns out to be not just me holding it wrong :-).

Regarding the TPM: I read https://trmm.net/Heads_33c3/#tpm-and-encryption and now wondering a) what does heads do if no TPM is present b) what are the options here to work around this ?

Turns out, it was a parallel build artifact. By calling make libusb it was solved .

I now have heads-FW4B-v0.2.0-1163-g8033f45.rom wohoo.

FMAP REGION: COREBOOT
Name                           Offset     Type           Size   Comp
cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           29608 none
fallback/ramstage              0x74c0     stage           78671 LZMA (172280 decompressed)
config                         0x1a880    raw               842 none
revision                       0x1ac00    raw               724 none
build_info                     0x1af00    raw                95 none
fallback/dsdt.aml              0x1afc0    raw              9566 none
fallback/postcar               0x1d580    stage           20012 none
fallback/payload               0x22400    simple elf    5769136 none
(empty)                        0x5a2c00   null           774564 none
fsp.bin                        0x65fdc0   fsp            307456 none
(empty)                        0x6aaf00   null           597732 none
bootblock                      0x73ce00   bootblock       12224 none

Not sure if i should flash it until i understand the implications of not having a TPM.

Not sure if i should flash it until i understand the implications of not having a TPM. Without a TPM, coreboot doesn't have any way to report any measurements of what is going to be executed next. There were a lot of discussions in other issues, heads-wiki I remember, on that subject.

Coreboot included TPM support in their vboot+measured boot support at 4.10 if I recall well, then splitted vboot from measured boot later on. Basically, coreboot uses the TPM from the bootblock (on most platforms) to measure itself and then extends measurements of its ramstage, romstage and payload prior of jumping in it (Heads is a Linux payload of coreboot).

Then Heads uses its tpm toolstack to extend the measurements with modules loaded, the public key injected inside of the ROM, and uses that so seal a known state inside of the TPM nvram region. Heads can also seal/unseal another nvram region (Disk Unlock Key) so that the LUKS header is also part of the measurements, and accepts to unseal that LUKS key if the measurements matches what was sealed.

Combined, the TPM permits to Heads the best possible solution without ACM blobs. ACM blobs are required to have hardware root of trust anchored into CPU. In that case, Intel ACM blobs is first ran prior of coreboot bootblock. The ACM blob measures the bootblock, and then those measurements are extended from there.

Without ACM (the case here), there is no root of trust in hardware; the root of trust is in the bootblock.

Without a TPM, you do not have this external measurement capability, and basically, you can only be sure of the firmware state if you externally reflash the SPI chip prior of booting.

The only other possibility is to use the No-TPM implementation proposed by Purism, which trusts the firmware to not lie about its early state (flashrom is trusted to be good, sha256 (busybox) not being compromised and the final hash of flashrom backuped rom not being simply hardcoded inside of the rom so that that implementation is not lying on its state. That is the best summary I can give quickly.

linuxboot / heads

bzImage size issue while porting to new board #1140