bzImage size issue while porting to new board #1140
Comments
derpeter
changed the title
Indeed! Welcome aboard @derpeter!
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. CPU being Broadwell?
|
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?
no its brasswell, Celeron J3160
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: 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: 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: Questions around FW4B (for lazy web. Too lazy to search for it after having read Celeron)
|
|
Another note about blobs/x220/extract: is calling different options then: Where 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. coreboot: Lets remember that all the following were already assembled if you fail at bzImage: 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: Regarding TPM the kernel tells me Is this a road blocker for heads? I will open the device later an look for a TPM header. first things first: also maybe usefull flashrom output: 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/[email protected]/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. ''' 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. Not sure if i should flash it until i understand the implications of not having a TPM. |
|
@derpeter commented on derpeter@8033f45 |
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??
The text was updated successfully, but these errors were encountered: