3 ms·
Microsoft could have contributed to coreboot instead if they claim to be so opensource-friendly. Or wrote firmware in safer language like Rust. Tradional UEFI c
by xvilka 8y ago
Microsoft could have contributed to coreboot instead if they claim to be so opensource-friendly. Or wrote firmware in safer language like Rust. Tradional UEFI code is a total mess, from programming practices view and from security/safety point of view too. For a long time they stuck with Python 2 only for their tooling, C89 compatibility, non-standard types, etc.
P.S. Note, that most of the UEFI is not open source - so called PI code (Platform Initialization), which performs real platform booting is closed source in almost any board. Coreboot is targeting this stage too.
- bpye 8y agoThis project and coreboot seem to me, complimentary. It is already possible to run TianoCore over coreboot, it seems it should be possible to run Mu with it as well given some work. Disclaimer: I do work for MSFT but never on UEFI - this is an outside observation
- cyphar 8y agoIf Project Mu requires UEFI, then you'd need coreboot+TianoCore+Mu. In theory contributing to coreboot would have been far more useful, but their idea of being able to easily update firmware would work better on UEFI. Coreboot does allow easy flashing by default but it's not really meant to be enabled on user systems (since it allows for "firmkits").
- bpye 8y agoI'm not sure if I've misunderstood but I'm pretty sure this replaces TianoCore [1], incorporating some of its components. [1] - https://microsoft.github.io/mu/WhatAndWhy/layout/ https://microsoft.github.io/mu/WhatAndWhy/layout/
- bravo22 8y agoPI code on x86 is provided by Intel. You can't ever open source it. Coreboot, like other offerings, sets up the basic stack and jumps to Intel provided blob, which then jumps to the provided hook in Coreboot when a particular part of initialization is done. DDR controller, microcode patching are all done at start-up via this mechanism.
- xvilka 8y agoNot for app CPUs, some configurations were freed from FSP needs, because all code was implemented from scratch.
- bradfa 8y agoIntel claim one reason that you just have to trust their binary blob PI/FSP to do these kinds of things is because at each stepping release of a given CPU there are different early boot errata and microcode abilities until microcode is loaded from flash. It's a bit of a stretch, but the insulation can be thought of as useful in the right light.