[coreboot][GSoC] idea for a proposal project porting to a Thinkpad AMD Ryzen 3rd gen machine
Hi all Coreboot folks,
I'm a first year graduate student in CS, been hanging around on #coreboot IRC (Libera.Chat server) and was thinking if it was possible or not to port Coreboot to a Thinkpad T495 (AMD Ryzen 7 3700U PRO) [1] manufactured in May 2019, I successfully dumped the BIOS using flashrom internally, see `flashrom_info.log` and 'flashrom_info.err.log`.
It is unclear if there is any AMD protection that does the same as Intel BootGuard on Ryzen 3rd gen (there is for sure this [2] since the 1st gen of Ryzen which is the equivalent to Intel Management Engine).
AMD has a whitepaper stating that from Ryzen 5000s mobile generation [3], AMD PSB (Platform Secure Boot) is activated, and it looks like kind of the same as Intel BootGuard if I'm not mistaken here.
I know so far that the BIOS SPI chip is operating at 1.8v, and is a Winbond flash chip "W25Q128.W" (16384 kB, SPI), will be useful in case I need to externally flash the SPI ROM to unbrick the laptop.
I still have to : - Test whether there is a protection that checks if the firmware was changed or not by patching the original bios ROM, I was told for this to change a copyright string or changing the logo : - it is a gif file and has a sha2-256 signature in its properties, which isn't the sha256sum of the file. - I've attached the `identify -verbose logo.gif` output) and trying to boot could allow checking for any tamper protection on the ROM flash (bricking intentionally the device if there is). - Understand if the EC RAM is something I can make out of or not (so far there is a lot of FF and 00 in it, the last line shows the version of the embedded firmware), so far I'm not too sure I can make sense of it right now. - Get the model of the EC and try to find datasheets online.
I have at my disposal: - A kind of cheap 16 channel logic analyzer [4] with a software available on Linux/Windows with a few decoders for most known serial protocols such as SMBUS, I2C, SPI and more. - Raspberry Pi 3 model B+ (will be used as an external programmer, but I still need to find out how I could pull down the power to 1.8v since the VCC is 3.3v). - SOIC clip 8 pins (will be delivered to me in 2 weeks), I took the best one from this guide [5]. - A cheap multimeter with basic probes, capable of continuity test. And possibly more such as FPGAs by going to hackerspaces in my vicinity.
I have built Coreboot for qemu with the Seabios payload as the documentation for GSoC recommended, see coreboot-serial.log output attached as a text file.
In the case where there is indeed a protection, maybe a solution could be found by using a flash emulator (spispy ?) [6] but I need more details on this.
I am also aware that a complete port will not be feasible under the time period of GSoC hence I need to know what should be the basics that needs to be covered for a Coreboot port to be considered minimally working first ? USB should work ? Charging is made using a USB-C port, this might be partly handled by the EC Embedded Controller.
Finally, if nothing could be done on this Thinkpad because it is too recent, I also have an older Intel Thinkpad a T450, that has Intel BootGuard but that I'm looking try to port Coreboot to it too, using a flash emulator and possibly this attack [7].
Thanks for the time taken to read this lengthy mail, I hope the goal of this mail is clear.
Kind regards, Lahfa Samy
Links: ------ [1] https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_T495/ThinkPad_T49... [2] https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor [3] https://www.amd.com/system/files/documents/amd-security-white-paper.pdf [4] https://sigrok.org/wiki/Kingst_LA2016 [5] http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate [6] https://github.com/osresearch/spispy [7] https://trmm.net/Sleep_attack/
Hi Lahfa Samy,
I was a GSoC student in 2020. I had already been a coreboot contributor for some time, so I came up with a project idea of my own: add support for Intel Bay Trail to libgfxinit (see https://blogs.coreboot.org/blog/2020/08/31/gsoc-libgfxinit-add-support-for-b... for details). In a nutshell, I decided to implement support for "new" hardware. I eventually managed to make things work, but just in the nick of time. And I wasn't able to test everything (most notably DP/eDP) as I only had one board to test things with. Hmmm, this reminds me I should revisit these patches and get them submitted.
In general, adding support for new (i.e. not yet supported) hardware involves some degree of trial and error. This largely depends on how much the hardware being ported differs from already-supported hardware and how much documentation/resources are available. Here's some examples (they're Intel-specific because that's what I'm most familiar with):
- Porting an Asus LGA1155 (the socket for Intel Sandy/Ivy Bridge CPUs) desktop mainboard is (relatively) very easy: coreboot's Sandy/Ivy Bridge code has been tested on many different mainboards (Chromebooks, ThinkPads, other laptops, desktops and even entry-level servers with the same LGA1155 socket), including a dozen Asus LGA1155 desktop mainboards that can be used as reference. I've done Sandy/Ivy Bridge mainboard ports that booted successfully on the first try. - 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. - Porting a mainboard with an Intel Denverton-NS SoC is substantially more difficult, as parts of hardware init are done by the FSP (Firmware Support Package) blob. FSP is only publicly available as a binary, the source code is only available under NDA (Non-Disclosure Agreement). Moreover, upstream coreboot only supports two mainboards: scaleway/tagada and intel/harcuvar (an Intel reference board, and it's not a good example of a mainboard port). AIUI, most Denverton-NS development happens downstream, in forks that never get upstreamed. So, as very little Denverton-NS development happens upstream, most (upstream) developers don't really know about it, and porting such a board involves significantly more trial and error (and/or having access to NDA-only resources from Intel). - 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).
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.
On Thu, Mar 31, 2022 at 10:00 PM Lahfa Samy samy@lahfa.xyz wrote:
Hi all Coreboot folks,
I'm a first year graduate student in CS, been hanging around on #coreboot IRC (Libera.Chat server) and was thinking if it was possible or not to port Coreboot to a Thinkpad T495 (AMD Ryzen 7 3700U PRO) manufactured in May 2019, I successfully dumped the BIOS using flashrom internally, see `flashrom_info.log` and 'flashrom_info.err.log`.
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).
It is unclear if there is any AMD protection that does the same as Intel BootGuard on Ryzen 3rd gen (there is for sure this since the 1st gen of Ryzen which is the equivalent to Intel Management Engine).
AMD has a whitepaper stating that from Ryzen 5000s mobile generation, AMD PSB (Platform Secure Boot) is activated, and it looks like kind of the same as Intel BootGuard if I'm not mistaken here.
Yes, PSB seems to be similar to Boot Guard, but I don't know for sure. I don't know if earlier Ryzen generations have something like this, but if they do, I'd expect Lenovo to have enabled it on the ThinkPad T495.
I know so far that the BIOS SPI chip is operating at 1.8v, and is a Winbond flash chip "W25Q128.W" (16384 kB, SPI), will be useful in case I need to externally flash the SPI ROM to unbrick the laptop.
I still have to :
- Test whether there is a protection that checks if the firmware was changed or not by patching the original bios ROM, I was told for this to change a copyright string or changing the logo :
- it is a gif file and has a sha2-256 signature in its properties, which isn't the sha256sum of the file.
- I've attached the `identify -verbose logo.gif` output) and trying to boot could allow checking for any tamper protection on the ROM flash (bricking intentionally the device if there is).
- Understand if the EC RAM is something I can make out of or not (so far there is a lot of FF and 00 in it, the last line shows the version of the embedded firmware), so far I'm not too sure I can make sense of it right now.
- Get the model of the EC and try to find datasheets online.
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.
I have at my disposal:
- A kind of cheap 16 channel logic analyzer with a software available on Linux/Windows with a few decoders for most known serial protocols such as SMBUS, I2C, SPI and more.
- Raspberry Pi 3 model B+ (will be used as an external programmer, but I still need to find out how I could pull down the power to 1.8v since the VCC is 3.3v).
- SOIC clip 8 pins (will be delivered to me in 2 weeks), I took the best one from this guide.
- A cheap multimeter with basic probes, capable of continuity test.
And possibly more such as FPGAs by going to hackerspaces in my vicinity.
There's some 3.3V to 1.8V level shifter boards meant to be used with SPI programmers, they can be found by looking for "1.8v adapter" and look like this: https://i.imgur.com/vbrbT6P.jpg
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.
I have built Coreboot for qemu with the Seabios payload as the documentation for GSoC recommended, see coreboot-serial.log output attached as a text file.
In the case where there is indeed a protection, maybe a solution could be found by using a flash emulator (spispy ?) but I need more details on this.
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'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).
I am also aware that a complete port will not be feasible under the time period of GSoC hence I need to know what should be the basics that needs to be covered for a Coreboot port to be considered minimally working first ? USB should work ? Charging is made using a USB-C port, this might be partly handled by the EC Embedded Controller.
For the ThinkPad T495, I'd be impressed if coreboot manages to reach the payload.
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.
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.
Once I've got logs, my next goal is to make coreboot reach the payload and boot Linux. Then I can test what works and what doesn't work, and try to make these things work.
Finally, if nothing could be done on this Thinkpad because it is too recent, I also have an older Intel Thinkpad a T450, that has Intel BootGuard but that I'm looking try to port Coreboot to it too, using a flash emulator and possibly this attack.
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.
Thanks for the time taken to read this lengthy mail, I hope the goal of this mail is clear.
Thanks to you for writing the lengthy mail, and I'd like to apologize for my even longer reply.
Kind regards, Lahfa Samy
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Best regards, Angel
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
-
Angel Pons -
Lahfa Samy