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-bay-trail/ 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 <s...@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-le...@coreboot.org Best regards, Angel _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
