heads
heads copied to clipboard
linuxboot
LibremKey/Nitrokey with x220
With the current master branch, which includes the changes to the x220 configs, amongst others, a new CBFS size ("to fix 50 seconds boot delay problems"), I found that you cannot build Heads with the additional libremkey/nitrokey module because there isn't sufficient space.
Reverting to the prior CBFS size (0x7e8000) fixes that problem. With that change made to the coreboot-x220.config file and CONFIG_LIBREMKEY=y added to x220.config, my x220 boots incredibly quickly and everything works. To be honest, it appears to boot faster than the x230s I have used with either Heads or Pureboot. So it doesn't seem to bring back any 50 second boot delay problem that there was before (this is my first time with an x220 in heads so I don't know about the boot delay).
In addition, even before using the libremkey/nitrokey module, I found that current master cannot build Heads on an x220 that properly stores the GPG key. Each time I would reboot it would ask me to flash it afresh. Given the above, I suspect that this is also related to the CBFS size.
All of which leads me to believe that the CBFS size from "T420 initial support + X220 FBWhiptail Support #578" merged into the master branch on February 19 isn't right for the x220 and that it should revert to a CBFS size of 0x7e8000.
@SebastianMcMillan : can you do a clean build with prior proposed settings (add CONFIG_LIBREMKEY in board config and CBFS correction in coreboot config) and confirm 50 seconds delay is gone doing so?
tar cvzf archives.tar.gz ./build/coreboot-4.8.1/util/crossgcc/tarballs/ ./packages ./build/musl-cross-38e52db8358c043ae82b346a2e6e66bc86a53bc1/sources/ &&
make BOARD=x220 real.clean && rm -rf crossgcc ./build/* && tar zxvf archives.tar.gz && make BOARD=x220
Or, it would be time to create x220-libremkey board with different coreboot CBFS size?
Or, it would be time to create x220-libremkey board with different coreboot CBFS size?
Before doing that I would double-check on whether the new CBFS size is appropriate for the x220 at all. As I say, in my case I couldn't get the GPG key to save permanently. It would save and reflash and boot properly the first time. But then on shutdown it would start again as if there was never a GPG key and would ask me to flash one. The only changes made to get everything working from that build were (1) resize CBFS to old size; and (2) add librem key. Otherwise everything else was left as is. So my assumption is that the CBFS size should never have been reduced and its reduction wasn't necessary to fixing the 50 second boot issue. But that's just my uninformed assumption.
With a clean master, my X220 stores my gpg key just fine. Just got done with an interview, I'll add the config_libremkey flag and test to see if it stores the GPG key still.
With a clean master, my X220 stores my gpg key just fine.
Interesting. That is with the new CBFS size 0x700000 or the old one? Mine wouldn't store it, but will now.
Just got done with an interview, I'll add the config_libremkey flag and test to see if it stores the GPG key still.
The issue with the Libremkey was that it wouldn't build at all as there wasn't enough space with the new CBFS size (but was with the old size).
Yes, that is with the new size. also, I just built the libremkey build with the new size, and it's building just fine.
edit: I just pulled an updated version of master, and now it's erroring out. Looks like something changed that puts the size requirements above what's currently offered.
Reverting to the old CBFS does once again bring back the 50 second delay.
@SebastianMcMillan : the CBFS size is probably just not matching. (which is the hypothesis for the delay) Can you provide output of me_cleaner for CBFS region that can be put out there and adjusted ifd?
@merge: I'm still not understanding how to adjust CBFS size according to me_cleaner and ifd expended size output. Some clarifications for clearer understanding would be more then welcome.
Full image detected
The ME/TXE region goes from 0x3000 to 0x500000
Found FPT header at 0x3010
Found 19 partition(s)
Found FTPR header: FTPR partition spans from 0xcc000 to 0x142000
ME/TXE firmware version 7.1.13.1088
Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x
The AltMeDisable bit is NOT SET
Reading partitions list...
FOVD (0x00000400 - 0x000001000, 0x00000c00 total bytes): removed
MDES (0x00001000 - 0x000002000, 0x00001000 total bytes): removed
FCRS (0x00002000 - 0x000003000, 0x00001000 total bytes): removed
EFFS (0x00003000 - 0x0000c7000, 0x000c4000 total bytes): removed
BIAL (NVRAM partition, no data, 0x0000adce total bytes): nothing to remove
BIEL (NVRAM partition, no data, 0x00003000 total bytes): nothing to remove
BIIS (NVRAM partition, no data, 0x00036000 total bytes): nothing to remove
NVCL (NVRAM partition, no data, 0x000095d9 total bytes): nothing to remove
NVCM (NVRAM partition, no data, 0x000036fc total bytes): nothing to remove
NVJC (NVRAM partition, no data, 0x00005000 total bytes): nothing to remove
NVKR (NVRAM partition, no data, 0x0000f650 total bytes): nothing to remove
NVOS (NVRAM partition, no data, 0x00035c3c total bytes): nothing to remove
NVQS (NVRAM partition, no data, 0x00000def total bytes): nothing to remove
NVSH (NVRAM partition, no data, 0x000056b7 total bytes): nothing to remove
NVTD (NVRAM partition, no data, 0x00001e44 total bytes): nothing to remove
PLDM (NVRAM partition, no data, 0x0000a000 total bytes): nothing to remove
GLUT (0x000c7000 - 0x0000cc000, 0x00005000 total bytes): removed
FTPR (0x000cc000 - 0x000142000, 0x00076000 total bytes): NOT removed
NFTP (0x00142000 - 0x0004fd000, 0x003bb000 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0xed)...
Reading FTPR modules list...
UPDATE (LZMA , 0x10ea00 - 0x10ea92 ): removed
BUP (Huffman, fragmented data, ~43 KiB ): NOT removed, essential
KERNEL (Huffman, fragmented data, ~120 KiB ): removed
POLICY (Huffman, fragmented data, ~84 KiB ): removed
HOSTCOMM (LZMA , 0x10ea92 - 0x114018 ): removed
RSA (LZMA , 0x114018 - 0x118aab ): removed
CLS (LZMA , 0x118aab - 0x11d466 ): removed
TDT (LZMA , 0x11d466 - 0x12353d ): removed
FTCS (Huffman, fragmented data, ~16 KiB ): removed
Relocating FTPR from 0xcc000 - 0x142000 to 0x400 - 0x76400...
Adjusting FPT entry...
Adjusting LUT start offset...
Adjusting Huffman start offset...
Adjusting chunks offsets...
Moving data...
The ME minimum size should be 81920 bytes (0x14000 bytes)
The ME region can be reduced up to:
00003000:00016fff me
Removing ME/TXE R/W access to the other flash regions...
Extracting the descriptor to "ifd_shrinked.bin"...
Modifying the regions of the extracted descriptor...
00003000:004fffff me --> 00003000:00016fff me
00500000:007fffff bios --> 00017000:007fffff bios
Extracting and truncating the ME image to "me_shrinked.bin"...
Checking the FTPR RSA signature of the extracted ME image... VALID
Checking the FTPR RSA signature... VALID
Done! Good luck!
user@heads-x230:~/me_cleaner$ python me_cleaner.py -S -r -t -d -O out.bin -D ifd_shrinked.bin -M me_shrinked.bin ~/QubesIncoming/Insurgo/backup_x220.rom
Full image detected
Found FPT header at 0x3010
Found 19 partition(s)
Found FTPR header: FTPR partition spans from 0xcc000 to 0x142000
ME/TXE firmware version 7.1.52.1176 (generation 2)
Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x
The AltMeDisable bit is NOT SET
Reading partitions list...
FOVD (0x00000400 - 0x000001000, 0x00000c00 total bytes): removed
MDES (0x00001000 - 0x000002000, 0x00001000 total bytes): removed
FCRS (0x00002000 - 0x000003000, 0x00001000 total bytes): removed
EFFS (0x00003000 - 0x0000c7000, 0x000c4000 total bytes): removed
BIAL (NVRAM partition, no data, 0x0000adce total bytes): nothing to remove
BIEL (NVRAM partition, no data, 0x00003000 total bytes): nothing to remove
BIIS (NVRAM partition, no data, 0x00036000 total bytes): nothing to remove
NVCL (NVRAM partition, no data, 0x000095d9 total bytes): nothing to remove
NVCM (NVRAM partition, no data, 0x000036fc total bytes): nothing to remove
NVJC (NVRAM partition, no data, 0x00005000 total bytes): nothing to remove
NVKR (NVRAM partition, no data, 0x0000f650 total bytes): nothing to remove
NVOS (NVRAM partition, no data, 0x00035c3c total bytes): nothing to remove
NVQS (NVRAM partition, no data, 0x00000def total bytes): nothing to remove
NVSH (NVRAM partition, no data, 0x000056b7 total bytes): nothing to remove
NVTD (NVRAM partition, no data, 0x00001e44 total bytes): nothing to remove
PLDM (NVRAM partition, no data, 0x0000a000 total bytes): nothing to remove
GLUT (0x000c7000 - 0x0000cc000, 0x00005000 total bytes): removed
FTPR (0x000cc000 - 0x000142000, 0x00076000 total bytes): NOT removed
NFTP (0x00142000 - 0x0004fd000, 0x003bb000 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0xed)...
Reading FTPR modules list...
UPDATE (LZMA , 0x1106c6 - 0x110758 ): removed
BUP (Huffman, fragmented data, ~47 KiB ): NOT removed, essential
KERNEL (Huffman, fragmented data, ~122 KiB ): removed
POLICY (Huffman, fragmented data, ~85 KiB ): removed
HOSTCOMM (LZMA , 0x110758 - 0x115d33 ): removed
RSA (LZMA , 0x115d33 - 0x11a7e4 ): removed
CLS (LZMA , 0x11a7e4 - 0x11f1f7 ): removed
TDT (LZMA , 0x11f1f7 - 0x1253a3 ): removed
FTCS (Huffman, fragmented data, ~15 KiB ): removed
Relocating FTPR from 0xcc000 - 0x142000 to 0x400 - 0x76400...
Adjusting FPT entry...
Adjusting LUT start offset...
Adjusting Huffman start offset...
Adjusting chunks offsets...
Moving data...
The ME minimum size should be 86016 bytes (0x15000 bytes)
The ME region can be reduced up to:
00003000:00017fff me
Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME...
Removing ME/TXE R/W access to the other flash regions...
Extracting the descriptor to "ifd_shrinked.bin"...
Modifying the regions of the extracted descriptor...
00003000:004fffff me --> 00003000:00017fff me
00500000:007fffff bios --> 00018000:007fffff bios
Extracting and truncating the ME image to "me_shrinked.bin"...
Checking the FTPR RSA signature of the extracted ME image... VALID
Checking the FTPR RSA signature... VALID
Done! Good luck!
We don't have consistent changes to the regions. That could explain why the OP doesn't have the issue.
We don't have consistent changes to the regions.
Which reinforce need to have blobs disclosed somewhere to have consistent CBFS region defined. :) #307 for the win!
@SebastianMcMillan @techge @eganonoa
We don't have consistent changes to the regions. That could explain why the OP doesn't have the issue.
python me_cleaner.py -S -r -t -d -O out.bin -D ifd_shrinked.bin -M me_shrinked.bin ~/QubesIncoming/Insurgo/backup_x220.rom ?
Yes, I did that with my x220 backup and got the results above. Edit: full output is now in my comment above
@merge: What to put in CBFS with logic explanation?
00003000:004fffff me --> 00003000:00016fff me
00500000:007fffff bios --> 00017000:007fffff bios
00003000:004fffff me --> 00003000:00017fff me
00500000:007fffff bios --> 00018000:007fffff bios
I've changed the region to 0x750000 and it doesn't delay and it builds. It stores my gpg key on the libremkey builds. I do not have a libremkey to test if libremkey functionality works as expected, however.
Do agree with above: what to put in CBFS with calculations would be helpful.
@SebastianMcMillan : well, we are not basing ourselves on the same version.
Yours:
- ME/TXE firmware version 7.1.13.1088
- BUP (Huffman, fragmented data, ~43 KiB ): NOT removed, essential
Backup I had in hands:
- ME/TXE firmware version 7.1.52.1176 (generation 2)
- BUP (Huffman, fragmented data, ~47 KiB ): NOT removed, essential
Goal would be to specify, minimally, original ROM that needs to be applied on Lenovo prior of extracting ROM for consistency in blob directory. On X230, the goal is to apply the latest EC not considered for signature validation, for easy revert of original BIOS reflash, that original BIOS needing to be backuped (2.75, 2.76)
Just realized, but this problem affects T420 as well, since the T420 and X220 are practically identical devices in terms of the flashchip.
I'll make a band-aid fix for both devices, PR opening up in a second.
I've changed the region to 0x750000 and it doesn't delay and it builds. It stores my gpg key on the libremkey builds. I do not have a libremkey to test if libremkey functionality works as expected, however.
Just to say, I've tested it with this CBFS size and indeed it all works, including the Libremkey and with no major delay. It isn't nearly as snappy as with the original 0x7e8000. That really is near instantaneous and must mean that the libremkey add-on is just the perfect size. But it will do if you're going with one x220 board (I did the vanilla, no Libremkey, with the 0x7e800o size just to see the delay and it was horrible).
@eganonoa : there is no magic here. 1- Upgrade to latest Lenovo x220 rom image not causing Heads prejudice (Version: no idea for x220) 2- Have ifd and me reduced accordingly by precedent me_cleaner command. 3- Put resulting ifd and me blobs under ./blobs/x220 directory 4- Fix CBFS size defined under coreboot heads config accordingly for x220 (calculation recipe welcome) 5- No delay and maximal CBFS size available.
Waiting for input to do this correctly (legally, challenging status quo) and provide those binaries like for #307.
It isn't nearly as snappy as with the original 0x7e8000. That really is near instantaneous and must mean that the libremkey add-on is just the perfect size
Last time I checked, cbfs size does not correlate to how snappy or sluggish the build is?
@eganonoa : there is no magic here. 1- Upgrade to latest Lenovo x220 rom image not causing Heads prejudice (Version: no idea for x220)
Ah, there you go. I stripped it all out from rom image pulled off of my x220 that was (a) running the modified version of bios 1.46 that you use on the x220 to unlock various advanced settings. (see http://x220.mcdonnelltech.com/resources/) (bios available at http://www.mcdonnelltech.com/X220_v1.46_Modified_BIOS.zip); and (b) had the 2017 ME firmware update applied (https://pcsupport.lenovo.com/se/en/downloads/ds014884). Used the script in the Heads master to pull out the blobs for the x220 directory, etc. Use 0x7e8000 CBFS size + libremkey and its near perfect.
I know nothing about the reasons why CBFS size should matter, but I can confirm that for me and based on a rom image with those two bits added: (1) master + 0x7e8000 - libremkey = 50 second boot time; (2) master + 0x750000 + libremkey = maybe 3-4 second boot time; (3) master + 0x7e8000 + libremkey = instant on.
I ran into this problem two weeks ago and tried with 0x72000 which works fine. If 0x75000 works, too that's even better. I do not understand why the boot delay happened with 0x7e8000 in the past, but not now for @eganonoa :thinking:
@techge @eganonoa @SebastianMcMillan : CBFS space should be smaller then available space defined in IFD, that is my only logical explanation: ME init/TPM measurements probably being confused and timing out (We see here that ME seems to suffer a lot!!!).
Played with CBFS calculations a bit for the x230 and successfully increased CBFS to 11.5Mb for xx30 here.
This is why we want reproducible, expended ifd, matching reduced neutered ME and consequent coreboot config CBFS defined region for a specific original bios version
So my recommendation would be:
- Flash latest original bios
- Backup SPI with external reprogrammer. Generate ifd.bin
- generate me.bin from latest available update.
- create a xx20 blobs directory, drop ifd there and README with instructions to regenerate it. Provide a xx20-blobs submodule that download, extracts me.bin consistently. Make coreboot config point to those blobs with expended maximum working CBFS size < ifd calculated region which builds successfully.
- modify board config flashrom options to not only flash the BIOS ifd region but flash all ROM, and differentiate board configs accordingly (input would be loved here: x230 having its x230-flash companion not requiring ME neutering nor ifd modification, x230-hotp_verification creating two externally flashable ROM images, unlocking ifd, neutering me and making all resulting CBFS space available and internally flashale for future upgrades)
Theoritically, those blobs should work for all Lenovo xx20 based boards:
ThinkPad T420, T420i, T420s, T420si
ThinkPad T520, T520i
ThinkPad W520
ThinkPad X1, X1 Hybrid(*1)
ThinkPad X220, X220i, X220 Tablet, X220i Tablet