[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument
Issue #421 has been updated by Julius Werner. > 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. Sorry, I still get the impression that we have a fundamental misunderstanding here. The TCG does *not* dictate how many hashes need to be logged in the TCPA log! (Or does it? If I'm wrong about this please clarify the exact spec and section that defines what hash algorithms *must* be present in the long, because I am not aware of any such requirement.) The TCG defined a log format that *allows* an implementation to log one or more hashes of different algorithms for each measurement entry. What exact algorithms and how many of them to use is entirely up to the implementation. So no, we would not be "putting another half-measure in place" that creates "yet another" standard. We would be switching to the exact TCG standard that you want (which I am generally not opposed to at all), we would use that exact format, and we would just *choose* to only log one hash for one algorithm in that data structure that is designed to hold one or more hashes depending on how the writer decides to fill it out. Because we don't have a use case for more than one hash. That's all I'm talking about. Cleanup #421: Change API of functions taking hash as an argument https://ticket.coreboot.org/issues/421#change-1220 * 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 - Bug #432] t440p reboots on suspend
Issue #432 has been updated by Josh R. Angel Pons wrote in #note-4: > Yes, it's definitely an osboot problem... Please report the issue to osboot > folks, and point them to this ticket. > > After grabbing the T440p IFD.bin that osboot uses and using `util/ifdtool`'s > `-d` option on it (after manually padding to 12 MiB; you can just use the > osboot image you built), it's clear why coreboot thinks the flash chip is > much larger... > > ``` > Component 2 Density: 32MB > Component 1 Density: 8MB > ``` > > Component 2 Density should be "4MB" (technically, 4 MiB) instead. No clue > where the IFD.bin that osboot uses comes from, but it's broken. See attached > log for the complete `ifdtool -d` output. I appreciate you looking into this. I have submitted an issue here: https://notabug.org/osboot/osbmk/issues/161 For what it's worth, there was some discussion here on using an extracted IFD from a Lenovo-provided archive: https://notabug.org/osboot/osbmk/issues/129 Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1219 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) osboot_t440p_ifd_bin_is_also_borked.log (10.2 KB) -- 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 - Bug #432] t440p reboots on suspend
Issue #432 has been updated by Angel Pons. File osboot_t440p_ifd_bin_is_also_borked.log added Yes, it's definitely an osboot problem... Please report the issue to osboot folks, and point them to this ticket. After grabbing the T440p IFD.bin that osboot uses and using `util/ifdtool`'s `-d` option on it (after manually padding to 12 MiB; you can just use the osboot image you built), it's clear why coreboot thinks the flash chip is much larger... ``` Component 2 Density: 32MB Component 1 Density: 8MB ``` Component 2 Density should be "4MB" (technically, 4 MiB) instead. No clue where the IFD.bin that osboot uses comes from, but it's broken. See attached log for the complete `ifdtool -d` output. Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1218 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) osboot_t440p_ifd_bin_is_also_borked.log (10.2 KB) -- 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. > 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 - Bug #432] t440p reboots on suspend
Issue #432 has been updated by Angel Pons. *sigh* where is the "Edit" button? Looks like the issue happens because something is messed up with the "ROM size"... ``` flash size 0x280 bytes SF: Detected 00 with sector size 0x1000, total 0x280 SF size 0x280 does not correspond to CONFIG_ROM_SIZE 0xc0!! ``` This seems like a bug in osboot. Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1216 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) -- 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 - Bug #432] t440p reboots on suspend
Issue #432 has been updated by Angel Pons. Hmmm, looks like the issue happens because the MRC cache Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1215 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) -- 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 - Bug #432] (Response Needed) t440p reboots on suspend
Issue #432 has been updated by Angel Pons. Affected hardware changed from Lenovo t440p to Lenovo ThinkPad T440p Status changed from New to Response Needed Hi, osboot is not the same as coreboot. Have you asked the people responsible for osboot to provide support? It would be great if you could test with upstream coreboot, to make sure the issue is in coreboot and not about something the osboot people did. Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1214 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) -- 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
