[HN Gopher] Libreboot: Freedom-Respecting Boot Firmware
___________________________________________________________________
Libreboot: Freedom-Respecting Boot Firmware
Author : guerrilla
Score : 195 points
Date : 2021-09-10 08:35 UTC (14 hours ago)
(HTM) web link (libreboot.org)
(TXT) w3m dump (libreboot.org)
| raffraffraff wrote:
| from libreboot import reboot
|
| reboot
| lifty wrote:
| I wonder if big cloud providers (AWS, GCP, Azure) have ways to
| deal with Intel ME or AMD PSP.
| smoldesu wrote:
| Probably not, since IME/PSP is what allows them to perform
| unattended reboots, remote BIOS modification and all the other
| wild VPS features we take for granted these days.
| oneplane wrote:
| Those features are probably of zero value in that
| implementation scheme for the big clouds. Those are more the
| kind of things for small datacenters and 'hosting providers'.
| wildfire wrote:
| That isn't true for AWS, the nitro card is used for all that
| jazz.
| seniorivn wrote:
| why would they want to?
| stefantalpalaru wrote:
| > it is a coreboot distribution
|
| It's parasitical removalware, riding on the real project's value
| and competing with it in market share after removing parts of it.
|
| I'd rather see an honest fork that's properly maintained than
| this.
| duskwuff wrote:
| That's a rather inflammatory way of putting it... but you're
| not wrong. As things currently stand, Libreboot is effectively
| just a fork of Coreboot with support for any x86 hardware newer
| than 2008 or so removed (because newer hardware requires non-
| free binaries which Libreboot refuses to touch). Short of a
| major change in Intel/AMD policy, I don't see any realistic way
| this will ever change -- which guarantees that Libreboot will
| only become more and more irrelevant as time goes on.
| oynqr wrote:
| I really wish Libreboot was run by a more stable individual. My
| eggs are in another basket.
| veltas wrote:
| People said the same thing about Linus for years.
| na85 wrote:
| Which basket?
| rofrol wrote:
| This https://www.phoronix.com/scan.php?page=news_item&px=Libr
| eboo...
|
| https://www.andrewrobbins.info/libreboot.html
|
| but later was apology from Leah Rowe:
|
| It should be noted, that I have apologized directly to John
| Sullivan (executive director of the FSF) and Richard Stallman
| (founder and leader of the GNU project, and president of the
| FSF). Both have accepted my apology, and are happy that I am
| doing this and that Libreboot will once again work with them.
|
| https://www.reddit.com/r/libreboot/comments/66tdds/proposal_.
| ..
|
| https://libreboot.org/news/rms.html
| Lammy wrote:
| > https://libreboot.org/news/rms.html
|
| Ultra-based. Thanks for changing my mind about Leah :)
| fsflover wrote:
| It should not matter too much who runs it, if the community
| verifies Libreboot.
| ctenb wrote:
| Brilliant name
| guerrilla wrote:
| I wonder if anyone has been working on disabling PSP[1] the way
| that people have done with IME. It looks like it's had at least a
| couple of vulnerabilities [2].
|
| 1. https://libreboot.org/faq.html#amd
|
| 2.
| https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...
| sodality2 wrote:
| Both of my devices' BIOS have an option to "disable AMD PSP".
| Can't really verify that it's off, though.
| garaetjjte wrote:
| That's switch for TPM features only. You cannot disable PSP
| as it is responsible for x86 initialization.
|
| https://www.youtube.com/watch?v=bKH5nGLgi08
| sodality2 wrote:
| I am pretty sure that switch just ignores PSP after boot;
| ie neutering it after it's necessary
| matthewfcarlson wrote:
| Right. Intel platforms do XIP to get through memory
| training but AMD relies on the PSP to train memory and
| setup other systems. So without the PSP it just wouldn't
| boot.
| salawat wrote:
| Sounds like a job for refactoring. Admittedly, I'm
| mystified what this "memory training" even is.
| POST->BIOS/UEFI->handoff to OS bootloader... Where's this
| memory training fit in?
| jabl wrote:
| > I'm mystified what this "memory training" even is.
|
| Modern high speed links are very finicky, to the extent
| that various parameters (timing, etc.) on each end of the
| link can't be hardcoded. The link training is part of
| initializing the link where the FW on each end of the
| link try out various parameters in order to enable full
| speed operation.
|
| > Where's this memory training fit in?
|
| I believe it happens even before POST.
| dfox wrote:
| On essentially every PC that supports different sizes of
| RAM modules the firmware has to jump through somewhat
| interesting hoops in order to configure/enable the memory
| controller. DDR4 training is just one part of this.
| Typical flow goes something like this:
|
| * All cores are brought out of reset. All cores start
| executing code from the end of 32b physical address
| space, hopefully some EPROM with firmware lives there.
| (One thing of note is that yes, intel says that there is
| no such thing as "unreal mode", but everything after i386
| boots into unreal mode)
|
| * Initial state of EDX signifies the position of CPU in
| SMP system, one core is designated as system processor,
| all other are application processors and thus do minimal
| APIC initialization and then enter halt and wait for IPI.
|
| * The system processor continues executing its firmware
| and its first order of bussiness is to configure cache
| controllers as to get even a few kilobytes of writable
| SRAM for its data area.
|
| * SP initializes enough of on-board PCIe devices to be
| able to access SMBus/SPD
|
| * SP scans SPD to get list of populated DIMMs, their
| sizing and timing
|
| * SP converts the SPD data into memory controller
| configuration and writes it there (note that at this
| point we are still doing XIP from slow-ish SPI Flash and
| have no RAM to speak of, so code that does this has to be
| very efficient, which is the reason for various RAM
| incompatibilities, as somehow common approach is to just
| hardcode expected configurations into the firmware).
|
| * SP looks into NVRAM if the DIMM configuration is same
| as was on previous boot, if it is it skips the next step
|
| * If it changed the SP enters the DDR4 link training
| algorithm. This essentially involves measuring lengths of
| wires from memory controller to individual DRAM chips.
| The idea there is that it is impossible to make them
| well-enough matched for the frequencies involved, so the
| deliberate difference is compensated for in logic and
| software (also it saves space on PCB of both motherboard
| and the DIMMs themselves).
|
| * The result of training is written into configuration
| registers of the DRAM chips and memory controller (and
| saved into NVRAM for next boot, as the training is
| somewhat slow)
|
| * We have RAM.
|
| * Firmware completes initialization of PCIe topology,
| enables LPC bridge.
|
| * Firmware does PCI(e) resource allocation. (The "PNP OS
| installed" switch in many BIOS configurations controls
| whether it configures all PCI devices or only these that
| it deems relevant)
|
| * We have something that looks like PC.
|
| * What one would call traditional PC-style POST happens
| now. First phase of ROM SCAN (in BIOS/CSM case) causes
| the VGA controller to come out of reset. Display turns on
| and user sees something like "Copyright (C) NVidia/AMD"
| in top-left corner
|
| * Firmware draws its splashscreen/UI.
|
| * Firmware completes all other initialization tasks (now
| running in somewhat sane environment). This involves
| entering protected mode and in CSM/BIOS case exiting it
| again (sometimes even multiple times). Various
| datastructures that are going to be passed to OS get
| filled in. List of boot devices is built. (this is the
| step that user perceives as "POST")
|
| * Bootloader gets loaded from whatever device was
| selected and control is passed to it.
|
| [Edit: and to make it even more interesting modern CPUs
| often need microcode update to be applied somewhere
| pretty early along this process]
|
| [Edit2: it is my understanging that on at least some x86
| server platforms the memory initialization is done by BMC
| although I'm not sure how exactly that works...
| bitbanging the DDR4 controller over JTAG?]
| oneplane wrote:
| Sidenote: Intel does that first stage before PCI/LPC root
| init using a bootrom on the CPU which also contains the
| hash of the RSA public key required to be used on the
| signed firmware it loads next. The enforcement policy on
| that depends on BootGuard fusing and the CSME/SPS.
| garaetjjte wrote:
| Right, that is how Intel does it. On AMD systems the PSP
| (which is ARM core integrated on the same die with its
| own on-chip SRAM) starts by loading its firmware from
| flash, initializes DRAM, does some other things, loads
| UEFI into main memory and only then releases x86 cores
| from reset.
| fsflover wrote:
| Purism in their Librem 5 separated that memory training
| into a separate (proprietary) chip and achieved blob-free
| software running on the CPU:
| https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-
| hurd....
| garaetjjte wrote:
| Which is meaningless philosophical exercise, as you still
| have the blob running anyway. (and now you cannot update
| it because it is in write protected memory, uh)
| fsflover wrote:
| AFAIK it's not running. At least it's not running on the
| CPU.
| garaetjjte wrote:
| It's not running on main core either way. It's blob which
| is loaded into DDR controller, and for some reason FSF
| thinks it is wrong to memcpy that blob using main cpu,
| but it is fine if you memcpy it using secondary core.
| rcxdude wrote:
| > Modern high speed links are very finicky, to the extent
| that various parameters (timing, etc.) on each end of the
| link can't be hardcoded. The link training is part of
| initializing the link where the FW on each end of the
| link try out various parameters in order to enable full
| speed operation.
|
| Exactly. Initialising DDR memory in any kind of system is
| a bit of a black art for this reason, even when the chips
| are soldered to the same PCB as the SOC, let alone when
| there's two unknown PCBs and two sockets in the mix.
| snvzz wrote:
| I remember when coreboot wasn't shit.
|
| It all went to hell when the website changed from a very
| functional wiki to some standard template filled with marketing
| buzz.
|
| They did then drop support for a lot of chipsets and boards, for
| some sort of commercial focus that as far as I can tell went
| nowhere.
| andagainagain wrote:
| Quick plug that system76 uses core boot in modern hardware. If
| anyone is in the market for a Linux pc anyways.
|
| Not sure if anyone else installs it by default, it's been
| awhile since I've looked.
| fsflover wrote:
| Purism installs it by default, too.
| mrjin wrote:
| Oh well, no more than a geek's toy if you want to keep up with
| relevant hardware specs. Obviously the government will never ever
| give up such a prevalent, versatile but yet transparent or
| stealthy management facility or rather rootkit/spyware, I meant
| Intel ME or AMD PSP. As there are asymmetric keys pre-embedded in
| the hardware, it would be hopeless for most of us to disable or
| even bypass it. In other words, we don't really own the hardware
| we bought as we simply have no (full) control over it.
| guerrilla wrote:
| At least Intel ME is actually in the PCH, so it's theoretically
| possible to bring up an Intel CPU without it by developing a
| replacement chip but from what I understand the PSP is
| integrated into AMD CPUs so there would be no way to develop a
| replacement. Both have had a lot of vulnerabilities though and
| there's been some success in partially disabling ME, nothing
| that I know of on PSP though. There have been plenty of
| vulnerabilities in both, so I wouldn't say it's hopeless even
| if ME did get chip integrated.
|
| I'm not sure why you think the government has anything to do
| with it though. I don't know what motivated them but I would
| suspect DRM lobbies first.
| mrjin wrote:
| Technically yes, you were right, there is a chance for us to
| intercept the communication between PCH and the Intel CPU
| then reverse engineer the protocol or even directly RE the
| PCH chip and create a substitute. But how practical, I don't
| really know. Firstly, the effort required is beyond most
| people can afford IMO. Put those cost/effort etc. aside,
| there might some undocumented CPU features actually need ME
| to work and if I were the designer, I would at least use
| signed if not encrypted payload, then make the RE process
| much less likely.
|
| Regarding why I was thinking the government(s) involve in it,
| actually it quite natural. At the very beginning, I would say
| it might be for IT management purpose only, and soon someone
| just like you mentioned DRM etc. get added to it. And I don't
| see a reason why government(s) don't see the value of it and
| would not want to get in as there is nothing better for large
| scale surveillance: built-in with almost every single
| machine, have access to virtually everything on the machine,
| powerful enough to do what ever they might want to do and
| most importantly, most people have no idea about it and even
| if someone like us happen to know it but nonetheless, we
| still almost absolutely have no way to remove it or at least
| disable it.
| guerrilla wrote:
| I'm sure states have an interest in these backdoors but I
| don't know of evidnece they're directly involved with it
| yet. It would be a natural fit as you say of course.
|
| > Technically yes, you were right, there is a chance for us
| to intercept the communication between PCH and the Intel
| CPU then reverse engineer the protocol or even directly RE
| the PCH chip and create a substitute. But how practical, I
| don't really know. Firstly, the effort required is beyond
| most people can afford IMO. Put those cost/effort etc.
| aside, there might some undocumented CPU features actually
| need ME to work and if I were the designer, I would at
| least use signed if not encrypted payload, then make the RE
| process much less likely.
|
| Well, yes, but I see this more as a project that would show
| up at DEFCON as a hack or maybe something commissioned by
| System76, Purism, Raptor, Pine or one of these companies.
| oneplane wrote:
| You can't bring up an Intel CPU when BootGuard is enabled,
| only Intel-signed firmware works for those.
| als0 wrote:
| Has anyone reverse engineered the link between the CPU and
| the PCH? I think it's called DMI.
| synergy20 wrote:
| https://www.linuxboot.org/ is another open source UEFI
| replacement too.
| threshold wrote:
| Coreboot was a great project for it's time. But if you want free
| hardware you need to build it yourself. As in from the RTL up to
| the keyboard.
| the_only_law wrote:
| > But if you want free hardware you need to build it yourself.
| As in from the RTL up to the keyboard.
|
| As unrealistic as it would be it would be an incredibly fun
| project if you could stick to it
|
| Not sure how it's licensed, but I can't help but the think of
| Niklaus Wirth and Oberon.
| j7ake wrote:
| I guess people differ in the definition of "fun".
| kook_throwaway wrote:
| There is an online course called nand2tetris where you
| build a whole computer from nand gate level (CPU, ram, ROM,
| memory-mapped display output, keyboard scanning, etc),
| write your own assembler and high level language, then
| program it to play tetris. It is, bar none, the most fun
| online course I've ever taken.
|
| https://www.nand2tetris.org/
| threshold wrote:
| If you want to be pragmatic there are FPGA boards and the
| SiFive Unmatched. Both are slow and require a degree of
| trust. But they might make a small home server. Of course
| just because it's open/free doesn't mean it's more secure.
| matheusmoreira wrote:
| Yes. So was free software. The idea that a worldwide community
| can build their own trustworthy software is amazing but it was
| subverted by hardware manufacturers and their backdoors and
| restrictions. We'll never be free until it's as easy to
| manufacture our own hardware at home as it is to write our own
| software.
| fsflover wrote:
| My problem with Libreboot is not only that supported hardware is
| very old [0], but that all those devices are vulnerable to
| Meltdown/Spectre, so you cannot run any untrusted code (not even
| Javascript).
|
| [0] https://libreboot.org/docs/hardware/#supported-hardware. It
| seems that the Chromebook is an exception?
| inshadows wrote:
| Are there any x86 CPUs out there that are NOT vulnerable to
| Meltdown/Spectre at this time? AFAIK not, and we're all paying
| performance hit[1], have lower resolution timers in JS runtime,
| and such.
|
| [1] https://news.ycombinator.com/item?id=22830330
| kop316 wrote:
| I have a Thinkpad X200 with libreboot, and with it, I install
| the intel-microcode and such so I have the updated protections
| on then.
|
| I personally feel that is a practical solution, as I have the
| FOSS bootloader, and I don't think Intel has backdoors in their
| microcode, it would much more likely be in Intel ME.
| fsflover wrote:
| Are you saying that you can update the microcode on Thinkpad
| X200? How did you do that? I thought Intel stopped supporting
| it.
| jabl wrote:
| Given the mention of 'intel-microcode', presumably the
| parent means the Intel CPU microcode that is loaded during
| Linux kernel boot.
| kop316 wrote:
| Yeah sorry, I should have been more specific, `interl-
| microcode` is a debian package that loads it on linux
| boot.
| fsflover wrote:
| But does it actually help against those vulnerabilities?
| mistrial9 wrote:
| Vcs-Browser: https://salsa.debian.org/hmh/intel-microcode
| kop316 wrote:
| AFAIK it does yes.
| kop316 wrote:
| AFAIK it is supported:
|
| https://wiki.debian.org/Microcode
| chuckee wrote:
| I think that's on purpose from the side of hardware
| manufacturers - newer systems make it impossible to use your
| own boot firmware. But I'm not sure - could someone confirm?
| rcxdude wrote:
| Yes. Both modern intel and AMD CPUs require a signed firmware
| on boot, and there's no way to adjust these keys. This
| basically kills any attempt to keep the boot process open
| (but doesn't completely stop attackers because the signed
| firmware is vulnerable to a variety of attacks).
| myself248 wrote:
| Can you go the other way, OLD enough that the relevant CPU
| features simply don't exist?
| DarthNebo wrote:
| Is Minix inside Intel Management Engine or the AMD equivalent of
| any concern? I'm not clear if the bundled firmware is already
| open sourced?
| guerrilla wrote:
| Check the FAQ. Both IME and PSP are covered.
|
| 1. https://libreboot.org/faq.html#amd
|
| 2. https://libreboot.org/faq.html#intel
___________________________________________________________________
(page generated 2021-09-10 23:01 UTC)