April 2022 - coreboot - mail.coreboot.org

Intel Quark - a quick update
by Andy Pont July 21, 2022

July 21, 2022

Thanks to the generosity of members of the list there are two Intel Galileo boards, a Gen 1 and Gen 2, on their way to me which should arrive towards the end of the month. As soon as they get here I will start testing the various configs to see what works and what is broken. -Andy.

7 10

[Proposal] Drop support for Ice lake [unmaintained]
by Tim Wawrzynczak May 30, 2022

May 30, 2022

Good day folks, In a recent change[0], it was proposed that we drop support for the Intel Ice Lake platform. The only mainboard supporting the platform was the Intel RVP, but as far as anyone knows, it appears the project never progressed past the initial silicon, and so the code is now unmaintained and also unused. Since Ice Lake is very similar to TGL & ADL, it poses a maintenance burden when dealing with Intel common code e.g., anything in src/soc/intel/common. According to [1], this should be announced in upcoming release notes first, and removal could happen in 6 months. Wondering if anyone has any thoughts on why we should keep it around, otherwise let's update the upcoming release notes to give the "official" notice that it will be dropped. Cheers, - Tim [0]https://review.coreboot.org/c/coreboot/+/60053 [1]https://doc.coreboot.org/releases/templates.html

2 1

Another day, another SMM loader vulnerability
by Arthur Heymans May 24, 2022

May 24, 2022

Hi After last week's SMM loader problem on all but the BSP, I noticed another problem in the SMM setup. The permanent smihandler is currently built as a relocatable module such that coreboot can place it wherever it thinks it's a good idea. (TSEG is not known at buildtime). These relocatable modules have an alignment requirement. It looks however that the code to deal with the alignment requirement is also wrong and aligns the handler upwards instead of downwards which makes it encroach either an SSE2 FX_SAVE area or an SMM register save state. It's hard to know whether this is easily exploitable. I would think that a carefully crafted SMM save state on the right AP arbitrary code executing might be possible. On the other hand I noticed last week that launching SMM on APs is broken too so this is likely a lesser problem. Anyway the fix is in https://review.coreboot.org/c/coreboot/+/63475 (It has a comment indicating what code was causing this problem) Please review and update your coreboot code! Kind regards Arthur

2 3

Open letter to Intel regarding the PSE on Elkhart Lake
by Zeh, Werner May 10, 2022

May 10, 2022

Dear coreboot community. I guess the most of you have seen the tension that was introduced to the community once Intel started to enable the Programmable Service Engine on the new IOTG SoC called Elkhart Lake (for reference, please see [1]). One of the outcome of this difficulties was to ask Intel for open sourcing the PSE code in order to avoid a new blob being introduced to coreboot. I took this action item and reached out to Intel in this regard. As a result I have had two meetings with the responsible people at Intel and they started to look into this request. So as of now Intel is analyzing the code to understand what needs to be done to open source it. What has been mentioned by Intel to me is that up to now nobody else have ever requested this for the PSE. Furthermore Intel let me know that it would be easier to convince the management layer to spend work on open sourcing the code if there would be more people from different companies requesting the same. My first guess was: we can do this! Therefore I have drafted up an open letter which I would like share with all of you: https://openletter.earth/request-for-opening-the-source-code-for-the-pse-on- elkhart-lake-26bad82a The wording have now been reviewed for two days between different parties and I would like to keep it as it is in order to get it done in time. This is now the moment where you can raise your voice! Please have a look at the open letter and sign it if you agree with the terms and if you support this approach. The more people we get the higher are our chances to be visible as an open source community. And it would be really helpful if we could get this letter signed by companies, this will for sure increase the traction of this request. I will keep this letter in "signing" state until 2021-12-09 07:00 am German time. Once we are there I will hand it over to Intel. Thank you for your support in advance Werner [1] <https://review.coreboot.org/c/coreboot/+/55367> https://review.coreboot.org/c/coreboot/+/55367

4 6

Question about compressed FIT payloads
by Krystian Hebel May 3, 2022

May 3, 2022

Hello coreboot community, For our work on POWER9 coreboot port we were using Skiboot [1] packed into FIT payload. While it worked fine, we wanted to provide users with easier way of testing it on hardware. I believe it may be possible to modify only one of PNOR (fancy name for flash given by POWER people) partitions. In order to do this, we would have to fit whole CBFS into 512k (actually 1M including ECC, but that would require non-power-of-2 size), which should be doable with LTO and compressed payload. According to [2], whole file compression is not available for FIT payloads. I understand that this makes sense, thanks to this we can decompress/load individual parts of payload (e.g. kernel and initramfs) once, otherwise we would have to decompress it to read metadata first and then move code around in memory. However, FIT format doesn't hold information about uncompressed sizes of its components, required by decompressing functions in coreboot. Instead, their compressed sizes [3] are used to initialize output region sizes [4] and those are then passed to decompressors [5]. Only FDT has a workaround to this problem [6], and kernel's size is calculated in an arm64-specific way in [7]. On other architectures components (other than FDT) are partially decompressed until they run of of space, silently ignoring the rest. What should be "the proper way" of getting uncompressed size? I can think of the following options, listed in no particular order: 1. Extend hack used for FDT to other components, use it for all compressed parts. Arbitrary size multiplier may either waste some space potentially overlapping other component's memory range or not be enough in edge cases (e.g. mostly zeroed file). 2. For LZMA you may get decompressed size from the header, unfortunately this is not possible with LZ4. 3. Dry decompression just to check proper size - sounds too costly. 4. New properties for components' nodes in ITS file. May need changes in mkimage, haven't looked yet. Preferably shouldn't have to be manually written to ITS as that would be prone to error. While playing with mkimage, may add automatic compression, right now it expects already compressed files in ITS, although this can also be scripted. 5. Add more arch- and payload-specific parsing of images, as was done for arm64. This may require some kind of mark that a payload needs special handling (new CBFS attribute maybe?) 6. Enable whole file compression of FIT payloads, which results in juggling in RAM. 7. Mix of the above. For our current issue we can also load Skiboot from another PNOR partition (from where it is normally loaded by Hostboot [8] which we are basically substituting with coreboot) and manually create FDT for it. This would however break normal coreboot boot flow and we would like to avoid that. [1] https://github.com/open-power/skiboot [2] https://doc.coreboot.org/lib/payloads/fit.html#supported-compression [3] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [4] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [5] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [6] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [7] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [8] https://github.com/open-power/hostboot -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com

2 5

Security notice: SMM can be hijacked by the OS on APs
by Arthur Heymans April 29, 2022

April 29, 2022

Hi When refactoring the coreboot SMM setup I noticed that there is a security vulnerability in our SMM setup code. It boils down to this: except on the BSP the smihandler code will execute code at a random location, but most likely at offset 0. With some carefully crafted code a bootloader or the OS could place some code at that offset, generate an SMI on an AP and get control over SMM. More recent silicon has hardware mechanisms to avoid executing code outside the designated SMM area (TSEG) so those would not be affected. The commit introducing this problem is https://review.coreboot.org/c/coreboot/+/43684. Roughly it affects most x86 builds from end 2020/ beginning 2021 till now. https://review.coreboot.org/c/coreboot/+/63478 fixes the problem. (Feel free to review the rest of that series as it makes the smm setup much more readable ;-)) Kind regards Arthur

9 11

2022-04-26 - coreboot UEFI working group meeting minutes
by coreboot org April 27, 2022

April 27, 2022

# 2022-04-26 - coreboot UEFI working group * Next meeting is 2022-05-24 * Meeting Minutes / Agenda Document: [1] ## Attendees * Martin, Jay, David, Nate ## Minutes Short meeting, few attendees and not much on the agenda. [Information] Here is an implementation of EFI support in rust, for cloud hypervisor. * [https://github.com/cloud-hypervisor/rust-hypervisor-firmware/tree/main/src/… * [https://github.com/cloud-hypervisor/rust-hypervisor-firmware/blob/main/src/… enumerates the services I guess they need. What’s the maintenance of the coreboot payload package? * They’re doing a lot of work, integrating the Universal Payload patches, but there may be a problem getting external patches reviewed. * They can reach out to martin at [gaumless@tutanota.com](mailto:gaumless@tutanota.com) What's the status of the patches being pushed to EDK2? * Unknown at this time. [1]:https://docs.google.com/document/d/13RjAddskjjCGhzIwxDTE1-w6HOIwhyoZsZUI…

1 0

25 April 2022 Self Describing Blob Discussion
by coreboot org April 27, 2022

April 27, 2022

# 25 April 2022 Self Describing Blob Discussion * Next meeting: 2022-05-09 * Meeting minutes Doc [1] ## Attendees: Sheng, Jay Talbott, Martin Roth, Werner, Ron, Zhiguang, Dun.tan ## Minutes: Continue discussion over New UPL (Universal Payload) document. These are a list of proposed fields and not so much a discussion about the encoding right now. Currently, the only thing being discussed is the format for passing data from init firmware (coreboot/UEFI/U-Boot/ X) to a payload. Not all payloads will need all fields, and all fields are optional. If a field that a payload needs is not given, the expectation is that the receiver will do its best to continue. If a field is passed, it should be treated as the As mentioned in the last meeting, there are 2 levels in the definition: * Key * Subkey General Format for data structure - Maximum of two levels. Example: ``` | Key | Subkey | CBOR type | Native type | |---------|--------|-----------|--------------| | Example | | Integer | Unsigned int | ``` CBOR requires a different field type for positive and negative values, so all ints are explicitly signed. The oreboot mailing list is suggesting something more coreboot-tables like. * The tables can have issues if not using the same compiler version. CBOR is just a definition for serialized data - it should be read in by the recipient once and copied to memory to put into a native structure. With either CBOR or CBTables, the structure needs to be known by both the sender and the receiver. An open source library will be provided that may be used to encode/decode the data into structures. We need to try to get representatives from ARM, AMD, RISC-V present for future discussions. We need different viewpoints in this discussion so that it isn't Intel & x86-centric. Graphics has a number of fields to pass to the payload. If these are not present, the payload should assume that graphics has not been initialized. The Universal Payload spec will be released as a Google Doc shortly and will be open for comments. * The Spec needs definitions of all fields. Pointers to other documents where they are defined are fine. [1]: https://docs.google.com/document/d/1IDQqr4cv8dQHa9faSxBc29xHSeKuXNTiMP3a3bL…

1 0

Request help and Support
by rainhenry＠savelife-tech.com April 26, 2022

April 26, 2022

Hello: I'm Rainhenry Wang from SAVELIFE Technology of Yunnan Co., LTD Company. We are currently developing a computer motherboard. Also want to use Coreboot to develop its BIOS firmware. It is based on Intel's Rocket Lake platform. The PCH model is FH82H510, and the spec code is SRKM2. However, I did not find Rocket Lake platform support code in all versions of Coreboot. So we want to understand and learn in detail how to add the code of another platform into Coreboot. I am not sure whether you have relevant learning resources or documents to share with us? Looking forward to your reply. Thank you very much. SAVELIFE® Technology of Yunnan Co., LTD 云南赛莱福科技有限公司王祥福 (Rainhenry Wang) Tel: +86-13104051251 (Voice calls only support Chinese) E-mail: rainhenry(a)savelife-tech.com

3 3

[coreboot - Bug #351] test issue for mailing list
by Felix Singer April 26, 2022

April 26, 2022

Issue #351 has been updated by Felix Singer. test 2 ---------------------------------------- Bug #351: test issue for mailing list https://ticket.coreboot.org/issues/351#change-900 * Author: Felix Singer * Status: New * Priority: Normal * Target version: none * Start date: 2022-04-25 ---------------------------------------- Testing the mailing list bot for coreboot. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0