Open derpeter opened 2 years ago
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?
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.
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)
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.
@derpeter commented on https://github.com/derpeter/heads/commit/8033f453a03cae4fc0d620419cb7971288743ad2#
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.
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:
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??