Hey there!
I personally didn’t test 1vyrain myself even yet, while understanding its internal functionality and advantages. Unfortunately, 1vyrain path to Heads is not recommended but for Heads legacy supported platforms. The idea of 1vyrain is to chainload exploits (vulns) permitting to bypass security measures in place to flash a 4mb firmware inside of SPI flash memory. This is a workable solution to flash skulls, fitting that requirement, or the x230-flash/t430-flash (to be renamed legacy boards soon) since only those firmware images are meant to be self-sufficient (boot) into an internal flashing environment. t430-flash/x230-flash roms then permit to flash internally x230/t430 or x230-hotp-verification/t430-hotp-verification roms, which won’t touch neither the Intel Firmware Descriptor (IFD) which is still locked (cannot be written to internally) nor Intel ME region. As a consequence, those “legacy” boards are considered “doomed” in the long term, since 8mb of BIOS region, as defined under the IFD is pretty limited for Heads. This is why Heads pushes users to go a bit adventurous and externally flash platforms once with maximized ROM images, splitted into 4mb(top) and 8mb(bottom) from a completely valid 12mb image (xx30 platforms) to take advantage of neutered ME space and then upgrade internally.
In a nutshell: 1vyrain doesn’t unlock the IFD (it can’t) nor it neuters ME (it can’t. 1vyrain can disable it, but that won’t survive flashing something else), since it can only flash 4mb firmware images, where x230-flash/t430-flash images can then call flashrom --ifd -i bios
, flashing only the BIOS region of the firmware(8mb) that is flashable without externally flashing the platform once. Maximized boards, being flashed externally once, contains a modified and unlocked IFD and a neutered unlocked ME region; instead of having only 8mb of BIOS region in IFD, it is extended to nearly the total size of the combined SPI space available (~12mb). Once running a maximized build, once can then upgrade internally through downloaded/compiled rom images
If the W540 is supported by coreboot (I missed that), then it should be documented under Platform blobs, collaborators/maintainers/testers for faster problems resolution · Issue #692 · linuxboot/heads · GitHub to be comparable to other boards, have a dedicated tester willing to externally flash (I do not own the platform).
Otherwise, i’m sorry about the confusion. I won’t port w540 to 1vyrain (not my project) while I can mentor porting under Heads in collaboration with a board owner that is willing to test things until the board is supported. One board inclusion ongoing for Heads is for the t440p, which is a really verbal port with a lot of technical details having been shared by the collaborator and what is desired to result into a successful inclusion and maintainership/testing under Heads.
A sad counterpart story for Heads is the t520 board. As one can see under collaboration/testing link: nobody has claimed recent ownership of such board and willing to test pull request (coreboot version change/kernel change that might impact booting of the platform with test images.
So questions:
- Why is the w540 interesting?
- What is the blobs status of that board? (work needed to create download/neutering scripts for ME, need of a memory init blob (mrc.bin?)
- FSP dependencies of coreboot?
- Presence of a dGPU (nvidia grahpical card? see work related to w530/t430 and others for blobs download and extraction scripts to support this second graphical card outside of Intel based iGPU)
- How interesting is the W540 for Qubes users?
If you are such willing contributor, you can open an issue under Heads!
Otherwise, I would suggest also creating an issue under skulls/libreboot for that platform (those projects are aimed at packing coreboot+seabios, resulting in small coreboot images).
If 4mb coreboot images are created by those projects, then you would be able to use 1vyrain (once supported) to use 1vyrain directly (with ME disabled) or use 1vyrain to test coreboot+seabios as an alternative to proprietary hardware through skulls/libreboot.
Fact checks:
Consequently, the first step would be seeing where that w540/w541 being supported by coreboot statement comes from
and how much people are interested into w541 (maybe @spergynerd you might consider renaming this to w541?)
Anyway!
- skulls/libreboot could include a w541 board without too much hurdle
- but that doesn’t resolve the issue of 1vyrain not having found a way to exploit full unlock to flash firmware even if it was available, internally through its deployment toolstack.
- Heads could have a board for w541 (not w530 since not coreboot supported), but those don’t seem to be really common so same reasoning as above would apply: Heads would need a w541 dedicated tester for testing new coreboot versions.