First of all thanks for your lengthy answer and all the information provided ! Here is my comeback (I hope such lenghty mails won't get me banned from the mailing list), had to go through some hoops but I think there is some hope for Ryzens Coreboot ports.
TL;DR: - AMD Ryzen/Epyc PSP has multiples vulnerabilities (last talk was in January 2022) reported recently (2 code executions have been covered in security talks by security researchers, links [1][1b][2][2b] at the end of this mail) but they're not simple to exploit, a serial port can be activated for debugging output it seems. - Idea for porting a Haswell Intel CPU I7-4710HQ for GSoC more doable, could I propose this for GSoC as the T440P is supported already ? - If there is no EC support, what is broken when Coreboot boots ? - Is there any documentation about SerialICE usage outside of Coreboot's doc ? - Coreboot's documentation for Picasso 17h AMD CPUs is only valid for Chromebooks ? - Someone ever made a binary diff of the PSP firmware from Chromebooks and modern laptops with Ryzens ? - Why even if Coreboot boots, it won't reach the payload easily ? - How does one trigger the `do_full_reset_()` function ? - Any idea (or pictures of common diodes found on motherboards) how could I confirm if there is a diode protecting my hardware from reverse polarity current (blowing things, I guess) ? - Can an ECHI controller from the Ethernet port or an SMBus controller be used for serial output when Coreboot has been booted ?
- Porting a Sandy/Ivy Bridge laptop is more complicated because one
also needs to add support for its EC (which largely consists of trial and error), but getting to the point where coreboot can boot to OS should still be rather easy in most (but not all) cases. In some cases, the EC firmware is on the same flash chip as the x86 boot firmware, so one has to avoid overwriting the EC firmware when flashing coreboot.
Is Coreboot porting just incredibly harder for Haswell and up generation (mainly because of Intel BootGuard) but in that case how was the ThinkPad T440P ported to Coreboot ? Was BootGuard not activated by Lenovo ? I understand totally the absence of documentation to be a real pain in order to figure out how to make a port behave very rightly and properly, having only NDA documents non accessible to everyone is really annoying.
Yes, maaaybe there's a way to bypass a protection mechanism specifically designed to prevent tampering with boot firmware. But what are the chances? What if no such way is found by the time the GSoC work period ends?
I totally agree with you on this one, for the GSoC period, an idea needs to be completed and not so theoretical, thus I want to ask how hard is it to port a Haswell Intel CPU, Intel 4th gen, this machine precisely : [4]. I've seen that the only laptop supported by Coreboot in this Intel family is the T440P, do you have any information on this ? Would it be realisticly possible under the GSoC time period constraints ? (not a complete port of course but at least getting to boot Coreboot and beginning to investigate serial debug output)
- Porting a mainboard with an unsupported Intel chipset is extremely
difficult and time-consuming (unless one has access to (normally, NDA-only) information that describes what needs to be done to initialize the chipset, then it's a matter of writing the code and making sure it works). While the high-level flow may be known, the hardware-specific initialisation steps are essentially arcane magic. RAM initialisation is by far the most complex thing that chipset code needs to do, and it's strictly required (can't do much without working RAM). AFAIK, the coreboot code for Intel Westmere (1st-gen Core iX) processors was written without access to NDA-only documentation, but from knowledge acquired through reverse engineering tools like SerialICE (and some parts were borrowed from Sandy/Ivy Bridge code). I don't know how long this took, but it definitely wasn't quick. And while the code seems to work fine on several laptops I've tried to port, it doesn't work on desktop processors (I'm still trying to figure out why).
Is there anywhere where is explained how SerialICE could be used (Coreboot's documentation only ?), I'm thinking to try and use it for future developpement, then but clearly maybe I won't delve into this for GSoC but at a later time.
Another thing to note: looks like some of your ideas assume that hardware-based firmware verification mechanisms (e.g. AMD PSB, Intel Boot Guard) can somehow be bypassed. If this assumption can't be proved by the time the GSoC work period ends, the student doing the project will have absolutely nothing to show for it, which would be tragic. In contrast, most project ideas listed in https://doc.coreboot.org/contributing/project_ideas.html can provide results even when they haven't been fully completed.
About the AMD PSB, the AMD PSP has been shown to have vulnerabilities in the past, in 2021 and January 2022, allowing code execution on the AMD PSP (and AMD cannot fix some vulnerabilities unless they recall the CPUs), the setup is really complicated, but it could allow to peer more into what could be done, in order to maybe make a port on Coreboot someday.
[1][1b] Slides 27-33 shows how code execution was obtained in the AMD PSP exploiting a bound check vulnerability which cannot be patched unless AMD recalls all affected CPUs (tested was the Ryzen 3500U, mine is a Ryzen PRO 3700U).
A voltage fault injection on AMD EPYC/Ryzen CPUs from Zen 1 to Zen 3 was found to allow code execution in AMD PSP bypassing the AMD Public key verification of the SPI firmware, there are no mitigations possible for AMD sadly, see page 4 of this research paper : [2] and this talk [2b], this clearly isn't simple but these works shows my assumption isn't completely far-fetched I guess.
I'm trying to figure out how to emulate my own AMD PSP (using this tool: https://github.com/PSPReverse/PSPEmu) but I'm having some difficulty as some steps are not very well documented (documentation is outdated), the emulator needs to be proxied to real hardware using either an expensive flash emulator or an UART interface, quoting "a single bit needs to be flipped in the System Management Network memory for UART to be activated", I think it would get activated on the AMD FCH (Fusion Chipset Hub) see [8], but I'm not sure if that's easily accessible neither what is the pinout.
I'm afraid that it's not as easy as it sounds. While coreboot has some code for AMD Zen-based platforms, it's specifically designed to be used with Chromebooks. The Ryzen 7 PRO 3700U is a Picasso SoC, so one could try using the existing coreboot code (and blobs: part of hardware init is done by AGESA code inside binary-only FSP, which runs on the x86 cores). However, I think the Chromebooks use special PSP firmware, so the code may not work on a non-Chromebook board. It doesn't help that (last time I checked) AMD's public documentation for Zen-based platforms is extremely thin (contains very little information).
So this Coreboot documentation [5][6] here is only aimed for Chromebooks ? AGESA blobs will still be necessary, as they seem to do very black magic stuff.
For the ThinkPad T495, I'd be impressed if coreboot manages to reach the payload.
Why is that, the hardware is really that much different than say Chromebooks with Ryzen CPUs ? Also on what grounds are you thinking that morden laptops and Chromebooks PSP firmware are different ? Has anyone confirmed this by dumping the firmware from bios updates from similar CPUs and trying to make a binary diff ?
I personally find ECs particularly annoying to port. Even with the EC's datasheet, the firmware it runs is most likely closed source. Some HP laptops have EC firmware that verifies part of the boot firmware, see https://doc.coreboot.org/mainboard/hp/hp_sure_start.html for details. That being said, ECs don't usually prevent coreboot from running. I've got several half-assed coreboot ports of laptops rotting on Gerrit: they boot to Linux fine, but EC support is missing and/or not working.
Given the amount of ThinkPads laptops supported in Coreboot, isn't it safe to think that there isn't any EC firmware that verifies part of the boot ? I may be wrong but as voltage for flashing depends on the SPI chip used on the target board and I think the tendance has been going from 3.3V to 1.8V however isn't it safer if the voltage is lower, power on less things no ?
Also what features could be broken because of the EC support being missing ? Charging the laptop ? USB/USB-C not working ? Keyboard backlight not working ? fTPM support would be broken ?
Not all boards are designed to be flashed in-circuit (without disconnecting the flash chip from the board, e.g. when using a SOIC clip). Finding out whether a board can be safely flashed in-circuit is not trivial, but boards that are designed for in-circuit flashing have a diode connected to the flash chip's VCC pin that prevents powering other components on the board. In-circuit flashing boards that are not designed for it is dangerous and could result in hardware damage.
You mean that flashing in-circuit could cause other hardware such as the Embbedded Controller or something else to lit up as well and send SPI messages whilst flashing (rendering flashing totally ineffective), or a capacitor due to reverse polarity could just blast the motherboard, hence the diode would protect from that ?
Do you have any idea what a diode usually looks like on a real PCB circuit, if there is like a bank of scanned motherboards with diodes near the SPI flash or something alike ? So I could probably take a look or maybe I should take high quality pictures/scans of my motherboard and post them online to check before doing any flashing in-circuit, the best approach would be to solder a socket for the SPI chip on the motherboard of the T495 (take it off when reprogramming it and putting it back in, see [3]) ?
I'm pretty sure flash emulators store the emulated flash chip's contents in RAM, so the data is lost when power is removed. Flash emulators are useful for development (commercial flash emulators can be reflashed much faster than regular flash chips) and for security research (e.g. Trammell Hudson's page on Boot Guard sleep attack, which you linked to). However, they're not practical outside testing environments. Imagine a laptop that could only run coreboot using a flash emulator: not only would one need to squeeze the flash emulator somewhere, but also make sure the flash emulator never loses power (or else the laptop won't boot anymore).
Thanks for your explanation, this is clearly not optimal indeed, seems like the last convenient solution that I could think of.
The first step would be to make coreboot run on the target board, where "run" means "I can see that the CPU is executing coreboot code". The simplest way to know coreboot is running on a x86 board that I know of is to execute a "power-cycle reset" (system powers off then on again), see the `do_full_reset()` function.
I believe you're talking about this function [7], how would one trigger this ? By configuring before building the Coreboot ROM image ?
After coreboot is doing something, it's a good idea to get logging output somehow, e.g. via a serial port (if the target board has UART/RS232), EHCI debug (only if the target board has an EHCI controller), or even flashconsole (coreboot logs get stored into the flash chip). However, the first two methods require the target board to have specific hardware, which is most likely not available/usable on the ThinkPad T495. The AMD SoC doesn't have any EHCI controllers (only xHCI controllers), and while it does have UARTs, they're not readily usable. One would need to know which components or test pads the SoC's UART pads are connected to (schematics would tell) and then locate these components or test points on the mainboard itself (boardview would tell) to carefully solder wires to, and that's assuming the SoC's UART pads are wired somewhere (they may not be). It should be possible to use flashconsole with the Picasso code in coreboot, but I'm not sure if it has been tested.
I see so reaching the payload isn't garanteed even if Coreboot boots, what does it looks like then ? If Coreboot cannot reach a payload, there is not much debug shown on the screen, probably the graphics aren't initialized yet or something along these lines or there could be at least textual output on screen ?
For the EHCI controller, could this help, or it is completely irrelevant as it should be an ECHI for the CPU ? 03:00.4 USB controller [0c03]: Realtek Semiconductor Co., Ltd. RTL811x EHCI host controller [10ec:816d] (rev 0e) (prog-if 20 [EHCI]) Subsystem: Lenovo Device [17aa:5125] Flags: fast devsel, IRQ 35, IOMMU group 12 Memory at d0818000 (32-bit, non-prefetchable) [size=4K] Memory at d0810000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [170] Latency Tolerance Reporting Capabilities: [178] L1 PM Substates Kernel driver in use: ehci-pci It is related to the Ethernet port on my T495 I believe.
There is also this SMBus device/LPC Bridge, not sure if that could be used in any way to have some debug output : 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) Subsystem: Lenovo Device [17aa:5125] Flags: 66MHz, medium devsel, IOMMU group 8 Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4, sp5100_tco
I can also confirm that I do have AMD PSP : 06:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor [1022:15df] Subsystem: Lenovo Device [17aa:5125] Flags: bus master, fast devsel, latency 0, IRQ 76, IOMMU group 16 Memory at d0400000 (32-bit, non-prefetchable) [size=1M] Memory at d05cc000 (32-bit, non-prefetchable) [size=8K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/2 Maskable- 64bit+ Capabilities: [c0] MSI-X: Enable+ Count=2 Masked- Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Kernel driver in use: ccp Kernel modules: ccp
I don't really know about security, but looks like this attack only works when the system is resuming from S3. I don't see how this could be used to run coreboot on machines with Boot Guard.
The only way I see this used, would be to bypass the Intel BootGuard check at boot leaving the original bios, and then having Coreboot after having bypassed the check, it's kind of a TOCTOU (time of check to time of use vulnerability) but this isn't very ideal as you've rightfully pointed out.
Thanks to you for writing the lengthy mail, and I'd like to apologize for my even longer reply.
It's all alright keep the lengthy mails coming, just curious on what's possible and what's not also getting more of an insight on what it really takes to port a device to Coreboot.
Finally, some vulnerabilities in the PSP have been fixed by AMD by now but many cannot be fixed, also given that there is no rollback prevention mecanism on my T495 thus I could flash an older BIOS and (maybe) rollback the PSP firmware that comes from inside the BIOS update. Still I believe there is a lot of work needed to get a Coreboot port going but some vulnerabilities have already been brought to light, maybe more could be uncovered in the near future as research progresses on this matter.
[1]: https://i.blackhat.com/USA-20/Wednesday/us-20-Buhren-All-You-Ever-Wanted-To-... [1b]: https://www.youtube.com/watch?v=KR8bPLj4nKE 14m : Could be a solution to serial output access for debugging. [2]: https://arxiv.org/pdf/2108.04575.pdf [2b]: https://youtube.com/watch?v=gwdlvLyPpZM from 12 minutes, relevant to the exploit. [3]: https://cdn.shopify.com/s/files/1/0076/6092/9091/products/Dediprog-SPI-Flash... [4]: https://icecat.biz/p/asus/n550jk-ds521h/notebooks-n550jk-ds521h-24978487.htm... [5]: https://doc.coreboot.org/soc/amd/psp_integration.html [6]: https://doc.coreboot.org/soc/amd/family17h.html?highlight=amd [7]: https://doxygen.coreboot.org/d9/d7c/cf9__reset_8c_source.html#l00030 [8]: https://doxygen.coreboot.org/d1/d66/soc_2amd_2picasso_2include_2soc_2uart_8h...
Also here is a very vague whitepaper about vulnerabilities on AMD Ryzens which are said to be related to the BlackHat talks and the arXiv paper I linked above : [9]: https://safefirmware.com/amdflaws_whitepaper.pdf