[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument
Issue #421 has been updated by Krystian Hebel. > I don't know what skiboot is... is that coreboot? Do they have a real use > case for having both hashes in the log or is it just another bootloader where > someone decided "might as well write all the hashes in advance just because > the spec technically allows for it"? > > My question is: is there any user of coreboot right now who would actually > turn on multiple hashes for production purposes because otherwise something > they need doesn't work for them? Skiboot is a payload currently used by OpenPOWER systems [1], like QEMU POWER9 or Talos II that is slowly being upstreamed [2]. With additional changes both to format of log created by coreboot and to the payload itself (latter breaks TPM2.0 logs), it could be persuaded to work with one hash, we did that as PoC for our setup that uses TPM1.2 (due to supply chain issues and low ability of I2C TPMs in general). However, instead of following existing standards, be it TCG or coreboot, such approach creates yet another one. Having the ability to use more than one would make transition to TPM2.0 easier, if not no-op. Since we are going to have to change event log generation code anyway, we want to do it properly, instead of putting another half-measure in place. So no, there are no users of coreboot that would use it right now, but there will (hopefully) soon be. As this is a change that will impact many platforms, we want to push it upstream sooner rather than later, leaving as much time for review and testing as possible. [1] https://github.com/coreboot/coreboot/tree/master/payloads/external/skiboot [2] https://review.coreboot.org/q/topic:talos-2 Cleanup #421: Change API of functions taking hash as an argument https://ticket.coreboot.org/issues/421#change-1217 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 All existing functions that take a digest as an input assume that only one hashing algorithm is used at a time. Crypto agile format entry can (and should) log every used PCR bank in one entry for a given measurement. To make it work, some of the arguments must be changed, e.g.: - pass number of algorithms used; - instead of algorithm ID, pass a pointer to array of such IDs, with size equal to above; - instead of hash, pass a pointer to array of hashes, with size and order as above. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument
Issue #421 has been updated by Krystian Hebel. Julius Werner wrote in #note-4: > Can you explain what use case you have that requires you to use multiple > algorithms? This allows for greater flexibility, where multiple coexisting programs may have different expectations, e.g. one is old enough to not know anything but SHA1, and another that considers SHA1 not secure enough. > And why is it not enough to just call tpm_extend_pcr() several times, once > for each algorithm? This would call `tcpa_log_add_table_entry()` (or its corresponding new version), which would create multiple entries. This is not allowed by specification [1], 10.1.6: > For each Hash algorithm enumerated in the TCG_PCClientPCREvent entry, there > SHALL be a corresponding digest in all TCG_PCR_EVENT2 structures. [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf Cleanup #421: Change API of functions taking hash as an argument https://ticket.coreboot.org/issues/421#change-1191 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 All existing functions that take a digest as an input assume that only one hashing algorithm is used at a time. Crypto agile format entry can (and should) log every used PCR bank in one entry for a given measurement. To make it work, some of the arguments must be changed, e.g.: - pass number of algorithms used; - instead of algorithm ID, pass a pointer to array of such IDs, with size equal to above; - instead of hash, pass a pointer to array of hashes, with size and order as above. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #420] Use standard format of TPM event log
Issue #420 has been updated by Krystian Hebel. Related links updated Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420#change-1107 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf Request to admin or someone with permissions to add as subtasks: - https://ticket.coreboot.org/issues/421 - https://ticket.coreboot.org/issues/422 - https://ticket.coreboot.org/issues/423 - https://ticket.coreboot.org/issues/424 - https://ticket.coreboot.org/issues/425 - https://ticket.coreboot.org/issues/426 Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Documentation #426] (New) Document existing and added TPM event log formats and PCR usage
Issue #426 has been reported by Krystian Hebel. Documentation #426: Document existing and added TPM event log formats and PCR usage https://ticket.coreboot.org/issues/426 * Author: Krystian Hebel * Status: New * Priority: Normal * Category: Documentation * Target version: none * Start date: 2022-10-12 Documentation should mention at least: - what formats are available and where they are described - what are possible consumers of each format - which hashing algorithms can be used - what additional info is added to that required by specification, if any - which component is extended to which PCR for each of supported scheme (may be in form of example event log) Additionally, existing vboot documentation should be fixed, especially parts describing SRTM and DRTM. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #425] (New) Add parsing of new TPM event log formats to cbmem utility
Issue #425 has been reported by Krystian Hebel. Feature #425: Add parsing of new TPM event log formats to cbmem utility https://ticket.coreboot.org/issues/425 * Author: Krystian Hebel * Status: New * Priority: Normal * Category: userspace utilities * Target version: none * Start date: 2022-10-12 All existing and newly implemented formats must be parse-able by cbmem. It should be able to automatically recognize used format and parse it accordingly, so there are no significant differences in invocation of this tool by end users. Crypto agile format will require implementation of additional unmarshaling. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #424] (New) Create and implement option to choose either TCG or vboot PCR assignment
Issue #424 has been reported by Krystian Hebel. Feature #424: Create and implement option to choose either TCG or vboot PCR assignment https://ticket.coreboot.org/issues/424 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 As with TPM event log, standardized TCG assignment should be chosen by default, with opt-in possibility to choose existing behaviour for platforms that depend on it. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #423] (New) Implement legacy and crypto agile TPM event log formats
Issue #423 has been reported by Krystian Hebel. Feature #423: Implement legacy and crypto agile TPM event log formats https://ticket.coreboot.org/issues/423 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 Legacy format is simple, it always uses SHA1 and its entries can be described by a C structure, with one field of variable length at the end. Crypto agile format is slightly more complicated. There can be more than one digest in entry, and their sizes depend on algorithm. There is code for marshaling of required structures in security/tpm/tss/tcg-2.0, but it assumes TPM endianness (BE), while entries in event log are always LE. Headers for both formats have vendorInfo field, which can be used to hold additional data, not described by specification. An example of such may be offset to next entry to be added, which saves code from walking through all entries (possibly with different sizes) for each new entry. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #422] (New) Create Kconfig menu for TPM event log format
Issue #422 has been reported by Krystian Hebel. Feature #422: Create Kconfig menu for TPM event log format https://ticket.coreboot.org/issues/422 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 New entries should default to one of TCG formats, depending on selected TPM family. Choice of other format shouldn't be restricted. Use of current proprietary format should be explicitly selected by boards that depend on it. Additionally, config menu should allow to choose at compilation time the hashing algorithms that are to be used. This would allow for limiting size of code for cases with restricted available space. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Cleanup #421] (New) Change API of functions taking hash as an argument
Issue #421 has been reported by Krystian Hebel. Cleanup #421: Change API of functions taking hash as an argument https://ticket.coreboot.org/issues/421 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 All existing functions that take a digest as an input assume that only one hashing algorithm is used at a time. Crypto agile format entry can (and should) log every used PCR bank in one entry for a given measurement. To make it work, some of the arguments must be changed, e.g.: - pass number of algorithms used; - instead of algorithm ID, pass a pointer to array of such IDs, with size equal to above; - instead of hash, pass a pointer to array of hashes, with size and order as above. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #420] (New) Use standard format of TPM event log
Issue #420 has been reported by Krystian Hebel. Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Measured boot and TPM standards
TL;DR: why doesn't vboot follow existing standards and tries to create its own instead? [XKCD] During our adventures with enabling coreboot port for Talos 2 we got to the point of enabling TPM, and with it, measured boot. coreboot's part worked without too many issues other than those resulting from assumptions about endianness, Skiboot's (payload) - not so much, at least it seemed that way. Hardware access worked after adding a driver implementation for new module, but it failed to parse event log and in result disabled TPM. Skiboot (payload) expects Agile format [TPM20] of event log, while vboot provides its own format [VBOOT], compatible with neither Agile nor legacy format used by TPM 1.2 [TPM12]. Even worse, address of this log is written to TCPA ACPI table, from which it is read and parsed (or at least tried) by kernel as TPM 1.2 format [LINUX]. At first I thought custom format was developed to add support for SHA-256, but only TPM 2.0 uses it, and it already has new format, capable of storing bigger hashes. Which brings up the question: why use own format that nothing else knows how to parse? Are there any reasons against switching to Agile format? AFAICT only cbmem can parse the current form. Another problem is PCR assignments: on one hand, [VBOOT] says that "coreboot uses the SHA-1 or SHA-256 hash algorithm depending on the _TPM specification_ for measurements", and then doesn't follow any existing specification, even though both families have predefined and mostly compatible with each other uses for PCRs (section 3.3.3 in [TPM12] and 3.3.4 in [TPM20]). Measuring GBB flags to PCR0 is dubious since PCR0 is usually used for code at or near RTM. Speaking of RTM, what the heck with those SRTM/DRTM definitions? When reading it, I got the feeling that there was misunderstanding and someone thought that S stands for software, D - discrete, although expansions of those abbreviations in the vboot documentation are correct. [DRTM] definitely isn't able to start from IBB, as is suggested in that documentation. We would like to work on mentioned issues, both implementation and documentation. Before we invest time in it, we would like to know whether there are any reasons that would require keeping current form, any caveats or design decisions we've missed. [XKCD] https://xkcd.com/927/ [TPM20] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf [VBOOT] https://doc.coreboot.org/security/vboot/measured_boot.html#tcpa-eventlog [TPM12] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf [LINUX] https://github.com/torvalds/linux/blob/master/drivers/char/tpm/eventlog/acpi.c#L105 [DRTM] https://trustedcomputinggroup.org/wp-content/uploads/TCG_D-RTM_Architecture_v1-0_Published_06172013.pdf -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Question about compressed FIT payloads
On 21.12.2021 20:34, Krystian Hebel wrote: On 18.12.2021 18:07, Nico Huber wrote: On 15.12.21 13:24, Krystian Hebel wrote: Hi Nico, On 15.12.2021 12:21, Nico Huber wrote: Hi Krystian, On 14.12.21 13:00, Krystian Hebel wrote: For our work on POWER9 coreboot port we were using Skiboot [1] packed into FIT payload. I might just miss it because I never worked with FIT, but maybe I'm not the only one: Can you elaborate why you chose FIT? Reading through your mail (and without further knowledge) it would just seem like the wrong choice. Good point, I spent so much time in this project that I treat too many things as obvious. Don't hesitate to ask if I omit something important. Skiboot must be supplied with information about hardware. Some of that is generated by code based on current configuration (e.g. number of cores, their IDs, memory amount and associativity), but a lot is always the same for a given platform or even whole architecture (BMC sensors, interrupt controller, register address space, LPC controller). Isn't this all or mostly information that coreboot has already available? It seems much like the situation on x86 with ACPI. We also had static ACPI tables that redundantly stored infor- mation at first. However, static ACPI tables were never treated first-class, sometimes even like an alien, and were prone to rot. Today, we try a good compromise between runtime generation and static tables (which can be extended at runtime). Not everything is defined in coreboot sources, AFAICT only XSCOM, LPC and one out of 3 I2C buses are used, rest (almost 600 lines in dts) is just static data. There is a lot of stuff that coreboot doesn't have to worry about, but Skiboot and OS do. This can be passed either in HDAT structure (Hostboot data, proprietary and mostly undocumented format in supposedly open firmware) or, as we learned after asking on OpenPower-Firmware mailing list, using FDT: https://lists.ozlabs.org/pipermail/openpower-firmware/2021-May/000641.html In our current setup that second, constant part is supplied as FDT in FIT image so it can be added as .dts file, which is easier to read and understand than C code that would be used for creating these nodes. Hmmm, I read above mailinglist thread. But I still miss the link to FIT. coreboot would have a dtb (doesn't matter if it generates it at runtime or a file in CBFS) and a payload (in CBFS or some other flash partition), right? Why do you need FIT? We don't _need_ FIT. We also don't need to implement new way of loading the payload if existing one is working as expected, more or less. Do you suggest removing FIT from coreboot completely? :) FIT code already does the heavy lifting: it parses dtb to modifiable format, appends firmware, compat and memory nodes (although the latter are added in different format than Skiboot expects and we have to modify it - both formats are compatible with spec, but not with each other...), gives opportunity for fixups to DT before repacking it, sets entry point and argument. Doing the same with dtb loaded from CBFS is possible, but it would result in mostly duplicated code. The only pieces of FIT that our code doesn't use are overlays and initramfs. Another option could be to split fit_payload() into two halves, first one would just load FIT from CBFS and choose appropriate config, second would be given kernel, initramfs and dtb as 'struct region' and work from there. That way we could mix various ways of obtaining pieces of the puzzle without duplicating code. Note that this would still leave bugs (normally I would called it "lack of implementation", but documentation says explicitly that this is supported) in the FIT decompression unresolved. Just FYI, we decided to switch to ELF anyway. Some of the code will be duplicated, but it still is less than the glue code that would have to be used otherwise. Problem with FIT payload (de-)compression is thus not resolved. -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Question about compressed FIT payloads
On 18.12.2021 18:07, Nico Huber wrote: On 15.12.21 13:24, Krystian Hebel wrote: Hi Nico, On 15.12.2021 12:21, Nico Huber wrote: Hi Krystian, On 14.12.21 13:00, Krystian Hebel wrote: For our work on POWER9 coreboot port we were using Skiboot [1] packed into FIT payload. I might just miss it because I never worked with FIT, but maybe I'm not the only one: Can you elaborate why you chose FIT? Reading through your mail (and without further knowledge) it would just seem like the wrong choice. Good point, I spent so much time in this project that I treat too many things as obvious. Don't hesitate to ask if I omit something important. Skiboot must be supplied with information about hardware. Some of that is generated by code based on current configuration (e.g. number of cores, their IDs, memory amount and associativity), but a lot is always the same for a given platform or even whole architecture (BMC sensors, interrupt controller, register address space, LPC controller). Isn't this all or mostly information that coreboot has already available? It seems much like the situation on x86 with ACPI. We also had static ACPI tables that redundantly stored infor- mation at first. However, static ACPI tables were never treated first-class, sometimes even like an alien, and were prone to rot. Today, we try a good compromise between runtime generation and static tables (which can be extended at runtime). Not everything is defined in coreboot sources, AFAICT only XSCOM, LPC and one out of 3 I2C buses are used, rest (almost 600 lines in dts) is just static data. There is a lot of stuff that coreboot doesn't have to worry about, but Skiboot and OS do. This can be passed either in HDAT structure (Hostboot data, proprietary and mostly undocumented format in supposedly open firmware) or, as we learned after asking on OpenPower-Firmware mailing list, using FDT: https://lists.ozlabs.org/pipermail/openpower-firmware/2021-May/000641.html In our current setup that second, constant part is supplied as FDT in FIT image so it can be added as .dts file, which is easier to read and understand than C code that would be used for creating these nodes. Hmmm, I read above mailinglist thread. But I still miss the link to FIT. coreboot would have a dtb (doesn't matter if it generates it at runtime or a file in CBFS) and a payload (in CBFS or some other flash partition), right? Why do you need FIT? We don't _need_ FIT. We also don't need to implement new way of loading the payload if existing one is working as expected, more or less. Do you suggest removing FIT from coreboot completely? :) FIT code already does the heavy lifting: it parses dtb to modifiable format, appends firmware, compat and memory nodes (although the latter are added in different format than Skiboot expects and we have to modify it - both formats are compatible with spec, but not with each other...), gives opportunity for fixups to DT before repacking it, sets entry point and argument. Doing the same with dtb loaded from CBFS is possible, but it would result in mostly duplicated code. The only pieces of FIT that our code doesn't use are overlays and initramfs. Another option could be to split fit_payload() into two halves, first one would just load FIT from CBFS and choose appropriate config, second would be given kernel, initramfs and dtb as 'struct region' and work from there. That way we could mix various ways of obtaining pieces of the puzzle without duplicating code. Note that this would still leave bugs (normally I would called it "lack of implementation", but documentation says explicitly that this is supported) in the FIT decompression unresolved. -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Question about compressed FIT payloads
Hi Nico, On 15.12.2021 12:21, Nico Huber wrote: Hi Krystian, On 14.12.21 13:00, Krystian Hebel wrote: For our work on POWER9 coreboot port we were using Skiboot [1] packed into FIT payload. I might just miss it because I never worked with FIT, but maybe I'm not the only one: Can you elaborate why you chose FIT? Reading through your mail (and without further knowledge) it would just seem like the wrong choice. Good point, I spent so much time in this project that I treat too many things as obvious. Don't hesitate to ask if I omit something important. Skiboot must be supplied with information about hardware. Some of that is generated by code based on current configuration (e.g. number of cores, their IDs, memory amount and associativity), but a lot is always the same for a given platform or even whole architecture (BMC sensors, interrupt controller, register address space, LPC controller). This can be passed either in HDAT structure (Hostboot data, proprietary and mostly undocumented format in supposedly open firmware) or, as we learned after asking on OpenPower-Firmware mailing list, using FDT: https://lists.ozlabs.org/pipermail/openpower-firmware/2021-May/000641.html In our current setup that second, constant part is supplied as FDT in FIT image so it can be added as .dts file, which is easier to read and understand than C code that would be used for creating these nodes. Note that this doesn't apply to QEMU port that is currently under review on gerrit. In that case FDT is created by QEMU and its address is passed in one of the registers; this is not the case on hardware platform where it has to be created either from scratch or, as in our case, from preexisting skeleton. -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Question about compressed FIT payloads
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/src/lib/fit.c#122 [4] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/lib/fit_payload.c#211 [5] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/lib/fit_payload.c#67 [6] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/lib/fit_payload.c#96 [7] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/arch/arm64/fit_payload.c#84 [8] https://github.com/open-power/hostboot -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to debug open-source AGESA with serial console?
Hi Paul, On 15.10.2020 10:53, Paul Menzel wrote: Dear coreboot folks, To get PCI bridge 0:15.2 enabled for the network device on the Asus F2A85-M PRO, I want to debug the PCIe General Purpose Ports lane configuration of the FCH. I’d like to print some variables in src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c over the serial console. It looks like #include and `printk(BIOS_DEBUG, …)` compiles, but the messages are not sent over serial console. Is that expected? Between InitReset and InitEnv (IIRC) redirection of serial port (and a few others) is disabled by default, this may be the reason why `printk()` doesn't work. If that is the case, building with `HUDSON_LEGACY_FREE` disabled may help. Do I need to use AGESA’s Integrated Debug Services (IDS) [1], and enable the console in `src/mainboard/asus/f2a85-m/OptionsIds.h`? Kind regards, Paul [1]: https://www.coreboot.org/images/3/36/AGESA_Interface_Spec_for_Arch_2008_v3.00.pdf Best regards, -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Linux kernel says "do_IRQ: 1.55 No irq handler for vector"
Hi all, On 03.05.2020 18:28, Nico Huber wrote: Hi Zheng, On 03.05.20 17:27, Zheng Bao wrote: I am debugging the AMD Picasso board. When Linux kernel boots, there is some error message in dmesg. do_IRQ: 1.55 No irq handler for vector We've noticed the same on PC Engines apu2, an older AMD board. So, for me there are two mysteries: 1. Why is IRQ 7 triggerred? IRQ 7 is a legacy spurious interrupt vector. It may be caused by the timer tick interrupt, see section 2.4.8.1.10 of [1] or appropriate document for other platforms. However, from what we have observed, this happens more often than 50% of time, so there may be another interrupt involved, one that is deasserted e.g. by INIT signal. 2. Why does the AP process interrupts before `sti`? (if my assessment above is correct). Did you run any payload between coreboot and the kernel? APs are enabled by AGESA, the interrupt might be latched since then and not because of whatever payload was doing. [1] https://www.amd.com/system/files/TechDocs/52740_16h_Models_30h-3Fh_BKDG.pdf -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Memtest86+ stuck
Hello, Hello Max, I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the very first tests. Always on the same point, 52%. Every release since 4.8 works this way, coreboot 4.7 works fine. Is this a known bug? Please try to apply the patch I did some time ago [1]. It is exactly the same issue I was having, except it hang at a different point IIRC. The cause of this is that when Memtest86+ is run as a payload, it expects that the memory map provided in coreboot tables is correct. It isn't, as SeaBIOS modified it and didn't update the coreboot tables. However, it keeps track of used memory in E820 properly, so other Memtest86+ binaries (e.g. emulated floppy or file on a disk) work. [1] https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/Y4BLTEDDMKIF33H55O2GL73A7GLIEBVE/ Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] Coffee Lake FSP Released
I agree, incorporating this with a build system would be great. It is a shame that folder structure leading to binaries is different in CoffeLake and Kabylake, which is a small thing but requires some workarounds. Issue has been reported, but nobody answered yet: https://github.com/IntelFsp/FSP/issues/3 I also started some work towards automating this, on top of Patrick's Georgi patches: https://review.coreboot.org/c/coreboot/+/28385/2 I hope this doesn't sound like bragging :) Regards, Krystian -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
