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-Know-About-The-AMD-Platform-Security-Processor-And-Were-Afraid-To-Emulate.pdf
[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-Socket-16-Pin_6_800x450.jpg?v=1579796392
[4]:
https://icecat.biz/p/asus/n550jk-ds521h/notebooks-n550jk-ds521h-24978487.html
[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_source.html
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
--
Kind regards,
Lahfa Samy
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
