I have come to bury the BIOS, not to open it [video]
osfc.io
osfc.io
Granted, UEFI is grotesquely complicated. Probably you could replace most of it with a EEPROM that has a mapping of device ID to memory address, and some instructions how to speak to the embedded controller (basically, ACPI).
Unfortunately, UEFI/ACPI or simliar seems to be going nowhere in the ARM world, so it doesn't seem installing Windows/Linux is going to be as easy on ARM as on x86 anytime soon.
Devicetree is a paired down version of OF; they retained the tree containing key/value device metadata, and dropped all the good bits.
Something like the missing Forth interpreter would be invaluable on development boards as well as for diagnostics on embedded devices. Or simply for fun. I used to spend hours exploring PowerMacs and Forth programming, all thanks to OpenFirmware.
UEFI still has this doesn't it? EFI byte code [0].
[0] - https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-gui...
Open source doesn’t mean not shipping binaries.
Having worked with ARM too I have to disagree. I found device trees really flexible and easy to get going.
However, I worked with Rockchip hardware so I had pretty good documentation, lots of examples, and source code for everything(for an old linux kernel, but still). This basically ensured I could do everything I wanted.
Of course, when a vendor doesn't provide documentation and example driver source this may not be so easy.
But even with Rockchip, different vendors have different levels of support. We had one potential vendor that had excellent documentation, delivered the source code to everything, and responded really quickly and helpfully - in english - to questions. But they were way to expensive. And we had another who just gave us some mystery Android + Linux images, GPL violation included. No schematics. I spent some time porting Linux from one board to the other - they were very similar - but never finished, and constantly was afraid of configuring a voltage regulator wrong and blowing it up, or something similar.
Compare to x86 where I can just order random parts form newegg, screw them together and pop in a boot USB drive, and it will mostly work. I know that you get what you pay for, but at least I would expect the SBC vendors to do hardware enablement, and provide some kind of abstraction that I can run my OS on (or upstream their code).
With EDK2, on x86?
Or configure and tuning some custom DDR that happen to be already soldered on the board? Or bootstraping some parameters from an EEPROM or external microcontroller?
Compiling and customizing EDK2 for x86 (to boot Windows) was a nightmare and I never want to do it again. I'd rather "make aboot -j8" my entire life.
Please tell me you've found the secret formula to automagically add ANY display panel purchased somewhere in Asia, on x86. Otherwise I'll back to praise the devicetree.
Everything I have came from 3 sources. There is a Linux BSP SDK file (36GB or so) and an Android SDK (75gb or so). Both have docs folders with lots of docs documenting various sdks (for the gpu, npu, camera etc). Those files also contain drivers source for old linux kernels that can be adapted to newer ones with a bit of work. Both are linked on pine's wiki under soquartz. Just Google soquartz pine wiki.
The third resource is just two parts of rk3568 TRM(same as rk3566) . They are here: https://github.com/heitbaum/rk3568/tree/main/doc
... as opposed to not having to "get it going at all"?
But that's exactly the point of device trees. You should be able to use generic ARM kernel build, and it loads appropriate drivers based on dtb provided by system firmware.
ACPI on x86 works the same way - it's in ROM but the OS doesn't necessarily use it blindly, it has plenty of quirks to interpret it with.
What do you mean by that? Every ARM server has UEFI/ACPI, and it's now looking like every new PC using ARM will include it out of the box. The Google Pixel smartphones use UEFI. There are even UEFI images for Raspberry Pi 4. Sure, the embedded space is probably going to be holding out for a while longer, but seems disingenuous to say UEFI is going nowhere in the ARM world.
You should be able to put vanilla Ubuntu on a SD card and pop it into a computer and get at least the basic features working. Instead, now you have the choice between opaque firmware images from the vendor (with an ancient kernel, and random additions to userspace), or building your own images with a lot of tinkering.
There is now a generic BSA https://developer.arm.com/documentation/den0094/latest (not server specific)
Even then, it would be even better if that library were open source that the OS could carry its own artifacts of. Not because open source is great, but so the OS can truly be in control. The point u/bcantrill makes about the OS not getting DRAM error information gives me cold sweats!
If the library is open source, then, yes, each boot loader and kernel will have to be built for the hardware it will boot on, at least until it gets far enough to get additional firmware/drivers from a boot image RAM disk or whatever.
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
From firsthand experience, I can say that at least installing Linux on a UEFI ARM system of the type that QEMU emulates was surprisingly straightforward, and even the ARM version of Windows seemed to detect the virtual hardware just fine.
...and I say this as someone who has worked on the PC platform for over 3 decades, and am a fan of the original BIOS. UEFI is a bloated mess, but it's better than nothing.
But a lot of ARM hardware is that type. The keywords are SBSA / SBBR / SystemReady. If your hardware is SBBR compatible then Fedora and Ubuntu's ARM64 iso, and Windows ARM64, downloaded from their website, will at least boot fine (drivers are a different question as always).
There's a good list of supported hardware in the lower half of https://community.arm.com/arm-community-blogs/b/architecture... . Many systems from Avantek, Gigabyte, NXP, Marvell, Solidrun etc are standardizing on this way of booting.
DeviceTree is low-level enough that you can implement UEFI on top of it. There's a UEFI port for the Raspberry Pi 4 at https://rpi4-uefi.dev/ that produces an SBBR layer, allowing it to boot any off-the-shelf ARM64 SBBR distro.
The major difference on X86 is that it is (for historical reasons) much more standardised at the hardware level than on ARM (at least on embedded ARM, there is more standardisation in the ARM server space). It also makes more use of discoverable busses like USB and PCI so the parts that need to be described in ACPI are smaller than the parts that have to be described in DT on ARM (as much is either "implicitly standardised" or on a discoverable bus).
And that is because all PCs are basically the same whereas there is a huge variety in ARM SoC hardware and boards, mostly for understandable reasons (there are a huge variety of use cases and price points in embedded systems).
If you were to build an embedded X86 system not using a PC architecture (North bridge, South bridege etc) but using the processor and your own design you would have exactly the same problem.
That said you don't have to have "hardcoded firmware images for every single device" in the embedded ARM world.
I build an in house BSP for a product family of ~15 devices based on 3 different SoCs and we have a single kernel and userspace (Debian based) for all of them. All the DTs are on the boot partition and the bootloader selects the right one based on hardware information (typically a small EEPROM).
The only part that has to be different is the bootloader itself (and then not different for every device but for each SoC) - so we have 3 bootloaders all supplied as part of the BSP and when building the install media we say which one to write.
Even that, in theory, could be avoided, at least on SoCs with the same ISA by improving u-boot a bit to make stuff like clocks configurable from data (the u-boot device tree) like the kernel already does. This may one day be possible once u-boot completely adopts the driver model.
That "describes itself to the OS" part is actually often being done by a complete OS as well.
> Unfortunately, UEFI/ACPI or simliar seems to be going nowhere in the ARM world, so it doesn't seem installing Windows/Linux is going to be as easy on ARM as on x86 anytime soon.
That's a really good thing. Bryan rants about ARM trying to go that way and thinks it's a terrible idea. I'm glad it's failing, assuming that's actually the case.
I'd be curious why because the PC model seems to be way more user-friendly, competition-friendly, and long-term-reliable than the current ARM model. I wish I could just download an ISO of Android 13 and install it on almost any Android phone like I could Windows.
Open Firmware—between the device tree system and the bytecode driver system—plus ELF provide a truly universal boot protocol for 32-bit and larger systems. And not only that, major and tractable implementations are now Open Source too, including things like the bytecode compilers.
It’s practically unconscionable that modern ARM and RISC-V don’t simply require Open Firmware boot support.
All the pieces are in place for RISC-V to effectively dodge boot chaos. Way before the server/workstation RISC-V hardware hit the market.
In ARM, it's a mess. Because ARM took way too long to do way too little re: boot standardization.
Imagine scaling that up to GPUs! The device needs to describe itself because IT is unique.
I encourage you to spend more time with it. Meet your hero. Get to know it. Understanding will surely follow. 8)
This is not "the x86 model". This is the "Microsoft refuses to support anything" model.
It is dead, and good f*ing riddance.
It's rather "Everyone wants to boot Windows, and Microsoft can't be bothered to deal with everyone" model.
But it's important to note that these days, there will always be somebody who wants to bring their code in at a lower level. And the immediate reaction of all vendors is "But why would you want to do that?". Why would you want to bring your own Unix flavor to our hardware? Why would you want to run Linux executables on Chrome OS? Why would you want to run a different hypervisor on Oxide racks?
Those people will exist. And layers like BIOS and UEFI allow system vendors to say "Eh, sure, we don't think that what you're doing is wise, but whatever, here's a standard way we'll allow you to use". Holistic systems don't have these standards. They are only usable as their creators intended. And not everyone will agree with their creators intentions. But the work required to refit them to fit another purpose, which the hardware is very fit to do, but the software fights against, is usually too high, and you'll be better off using something that is worse, but left you an avenue to customize it for your purpose easily.
My main takeaway from this talk, is that we need some standards for phase-based booting, as there is some very cool improvements that could be done with it. But I see no need for holistic systems as described in that talk, I just see a need for better, more transparent systems. And a system doesn't have to be holistic to be transparent, or good.
my takeaway is that it's not the holistic systems themselves that are needed -- it's that when holistic systems aren't enforced that vendors will go mad with power.
Holistic systems don't prevent vendors from going mad with power. Competition and pressure to document their products does.
Legal liability for broken, unmaintained firmware would very quickly bring about the world that BMC wants.
I just don't think it's realistic to expect every vendor to provide deep-enough documentation to make this work. Even the cooperative ones (of which I assume there are currently very few) would probably have trouble with it.
And even if you do have a bunch of cooperative vendors who are great at releasing hardware documentation, that still doesn't save every OS developer from the tedious, error-prone process of converting that documentation into low-level bringup code.
Isn't it so much better that a Linux developer, when confronted with a new board, need only craft a device tree description (or use one provided by the vendor), and then -- aside from any exotic peripherals that may not have drivers written yet -- the board will mostly work? It's at least likely to boot, even if it comes up in a not-fully-functional state.
And yet, holistic systems can lie. They can lie horribly about their state, and you'd be none the wiser. Being "holistic", created with the intention of the whole, does not mean that the system cannot lie. If the whole is created with the intention of lying to you, than it will.
We don't need holistic systems. We need good systems. A system doesn't need to be holistic to be good, and a system doesn't need to be good to be holistic.
If we go by those two requirements, we can see how it works. We can fix things ourselves. And most importantly, anyone can create their own good firmware, without the need for the system to be designed in a holistic way.
Watch here: https://www.youtube.com/watch?v=0bi1PvXCbr8
Rather than have one operating system that boots another that boots another, we have returned the operating system to its roots as the software that abstracts the hardware: we execute a single, holistic system from first instruction to running user-level application code.
...also known as single-purpose firmware for an embedded system. I'm in agreement with the other comment here that this is not a good idea. Standardised interfaces like what the BIOS provides lets the OS not be tied to subtle differences in hardware.
UEFI does have many of the features of a full operating system including shell, multiprocessing, networking and it really should be Linux in this position instead. LinuxBoot is another attempt at reducing layers here.
And yes, this is (as ever) a call to arms on fixing a massive security problem we all have.
I think the folks at Oxide are probably closer to the right track by silo-busting the BIOS, OS, and hypervisor layers of a modern VM-hosting stack.
Edit: I should also add that this talk lays out a huge, gaping hole in the field of OS research, which might be its most important contribution.
Cantrill and Roscoe both pointed at the SOC vendors: if there's a new problem to solve, they add more proprietary, undocumented, cores and enclaves with tightly held secret functions and OSes of their own, all of which are out of visibility of the OS. Some of them are even designed at odds with the user's interests, such as DRM goop.
This gets back to the war on general purpose computing as Cory Doctrow put it. The hardware is ceasing to work for the user's interest and is starting to work for everyone else in the stack against the user.
OSes are generally terrible at providing strict latency guarantees. If you will crash the CPU if you don't do [X] every 10 microseconds, you should not be telling the operating system to do [X]. This is the case of audio systems, radio systems, PCIe, and almost every other complicated I/O function. These could all be done with hardware state machines, but it is better (cheaper) to use a small dedicated CPU instead.
When I refer to security boundaries, a lot of people think that "security through obscurity" is the idea. It is not. It is more similar to closing all the ports on a server and applying "API security" ideas to hardware. It is a lot easier to secure a function that has a simple queue interface to the main cores than to secure a function that shares the main cores - Spectre and Meltdown have showed us that it might be impossible. Yes, these secure enclaves are used for DRM crap and other nonsense, so I can see why you might not like the existence of that core, but even if you erase the DRM software from that core and make it work for the user completely, you still will want the boundary.
Not to mention that every modern motherboard these days has a board management controller, which cannot be part of the CPU, and controls power and resets.
From a hardware perspective, these SoCs and motherboards really need to be heterogeneous systems. It's up to the system software to work with that. Heterogeneous SoCs really have nothing to do with taking power away from the user. The user can program all of these cores, but we live with abstractions that make it very hard.
We've added several small cores of our own to the systems that make up the Oxide rack, but critically we can control them with our own (open source) software stack. The large scale host CPUs where hypervisor workloads live can communicate with those smaller cores (service processor, root of trust, etc) in constrained ways across security and responsibility based boundaries.
Things like audio and radio functions (eg bluetooth and wifi) have algorithms that are very proprietary and often patent-encumbered. The hardware architectures for radios are also similarly weird and proprietary. That kind of thing would result in a binary blob (at best) in a fully-open-source environment.
Hot take: I don't mind if Dolby or a wifi chipset vendor hides their software from me as long as it has very strict definitions for its role and a very narrow I/O interface.
It is also a worry that the hidden code in the SoC's subsystems might be hidden for a reason, namely to give control of computers to someone other than the user and OS. That seems a perfect way to compromise all computers while giving an illusion of security. That's why the Intel Management System has been controversial (TPM's also), but in truth there are many processors on the SoC's that each have enormous security implications that the OS does not control. This has been an issue for decades. I remember people running code on the floppy drive MCU for Amiga's, so this has been known about for a long time. Cell phones are intentionally designed so the OS has no control over basic cellular radio functionality. There is a totally separate processor with its own non-public firmware controlling the radio. Whoever writes the code for these subsystems has enormous power with very little oversight.
The only solution to these problems is actually regulation and trust. There is just no realistic way to actually check that your system is not doing some of the things you don't want it to do. Instead, you have to go to the source and make sure you can trust the vendors you buy from, and in order to do so, they themselves have to have hiring and shipment etc practices that allow this type of trust.
Through whatever historical accident, the IBM PC is... pretty amazing. Things are standardized. Stuff just works. We can choose our OS. We don't have a ton of fragmentation. Distros aren't niche community things developed for specific hardware.
If you can make a single OS image that runs on any device of any manufacturer, the way that one Linux distro runs on almost any PC with any combination of parts, great.
But removing layers of abstraction seems like it could easily lead to incompatibility. I'd much rather have proprietary blobs everywhere than incompatibility.
However if you want to run a whole cloud or have significant amount of server hardware, you might now want to have 5 other core with random OSs doing random things, eating errors and so on and so on. Same goes if you want to make secure devices like IPhone, Chromebooks and so on. I would like my standard linux laptop to be like that too.
Also we could have both. If AMD/Intel documented these low level systems then the needed patches could flow into the linux kernel. You could likely boot LinuxBoot and still put UEFI on top if you really want to.
And if the system was that open you can still define layers of abstraction on top for situation where you want that compatibility. At the moment compatibility is forced on us with a really thicc layer of abstractions that do some useful things, but also do many not so useful things.
We'd probably wind up with 5 UEFI alikes, 3 distros that don't use any of them, and there would probably be subtle compatibility issues.
Eventually the consensus would evolve to some new standard, the way systemd has, and then everyone would complain about that being too heavy and how they don't want a monoculture.
Or, worse, we could wind up in the same place ARM is, for a decade.
There's no technical reason for it, but there also doesn't seem to be a very strong pressure to standardize.
Consumers aren't exactly going to unionize and engineers love to fragment, so to me a standard with that level of popularity is something special and should only be messed with if you have a real clear plan to preserve compatibility.
This, of course, isn't to say I wouldn't love to have a system where we can run our own open implementation on every bit of the platform, but rather that I don't believe we ever will. Oxide has made it pretty far, no doubt, and it's an incredible feat but as Bryan mentioned, their staff is literally reverse engineering hardware and finding completely undocumented cores in the things they're putting in charge of their platform. Hell, most companies I've been at hardly even know the full capabilities of their shipped silicon (did we slap a chicken bit on that? did we fuse off that performance analysis module for production runs? did we fully remove that one feature that didn't verify before our tapeout deadline? did we backport that one bug fix to all relevant generations? and on and on) and so its many times not even a case of companies being over protective but rather people not being able to even reason about these complex systems.
Both Bryan and Roscoe raise the question of who is at the helm of the ship and each find a different monster steering. The truth is that nobody is actually in control on these SoCs because nobody has the last word or some distinct power that cannot be compromised with some other random power. SoCs are not hierarchical; they're ridiculously complex systems of federated power, and we really need to treat them as such.
So what we need is compartmentalization and a blessed central core ... and that's hierarchy anyway.
Yes, of course 99.99..% it's a forgotten fuse or whatever legacy junk. But apparently some folks believe there's is a business model to be built on that last 0.00.. :)
Basically what they did is do a reverse engineering and replay attack on a boot sequence that is already so convoluted that the company that built it didn't think that would be possible.
Good for them but all this work will be wasted if the next hardware version comes around and needs a different boot sequence. They basically nailed themselves to a specific version of a specific hardware platform that AMD is replacing as we speak (the next iterations are called Genoa and Bergamo and are expected this and next year respectively.
I was hoping this would feel like a breath of freedom, but it really feels like a few rebellious nerds trying to prove something, but not actually proving it. The talk feels to me like they actually proved the opposite. We are already too far down the path. You will never be able to, say, boot Windows on this hardware.
Can you boot a stock Linux on this hardware, or will you be dependent on patches from them?
As a Linux user I love the idea. As a PC user I never asked for UEFI or the Management Engine. I should be all for this. But somehow I'm not.
UEFI secure boot is an example. Yes, it can increase security (although I think the threat is specific or outdated), but it can well be used to limit the user practically. And if such a mechanism is established, there will be a class system of trusted and untrusted devices. This is not a development that is hard to predict. So UEFI already failed to a large degree, at least regarding the openness of systems. It is no accident that some companies push these developments enthusiastically. It is not for user security, it is simply for market dominance.
As he says in the video, what is important is documentation. Their code will serve as open documentation for a lot of those details.
Sure with the next version there will be some changes, but likely much of it will still be the same. And when they upgrade their product they will have to integrate those changes.
For 'stock Linux' to boot like that it would need to add those same low level drivers and I don't know if there is a reason the phased approach shouldn't work on linux.
The hope is for many companies to do this and demand this documentation so that with each new version these things will quickly find their way into the open source software. This is now happening with coreboot where multiple companies collaborate on new CPU generations to get it in before the hardware is even released.
But with fireware there is never this amazing solution anybody can do unless the manufacture simply does it. Its sad but its the reality.
> Basically what they did is do a reverse engineering and replay attack on a boot sequence that is already so convoluted that the company that built it didn't think that would be possible.
That is not at all what was done here, and my apologies if I implied that it is. Indeed, quite the opposite was done: we determined how it actually worked and what the part actually needed -- discarding much of the needless gunk and repeated initialization. So it's not a "boot sequence" per se, it is initialization of various on-die components. Is this AMD-specific? Yes. Is it likely to change in Genoa, Bergamo and beyond? To a degree, yes -- but in broad strokes, unlikely. And because we have the OS (and importantly, its tooling) available where this enablement is taking place, we believe that we will be able to make the necessary changes for Genoa and beyond relatively faster than the extant approach of waiting for a proprietary BIOS.
Your approach is very laudable and I have in fact been fanboying it for a while. I wish you the best of luck and profits for your company. I sure hope this approach is more sustainable than my gut feeling told me after viewing your talk.
One question, if I may: How sure are you that AMD won't sue you at some point over this? Your ought to be in their best interest but that has rarely stopped legal departments in the past.
Where you see an "this is an awesome opportunity for a company, I'll found one", I see an "would I really want to base my business on something that AMD may at any time decide voids the warranty"?
* several different servers where you can set the boot order through the Redfish API, except that it only works about 60% of the time and there is no way to tell from the response if it took or not. Just have to keep doing it and rebooting until it hopefully eventually works!
* PXE boot support that is incredibly slow, so for any reasonable payload size you need to chainload iPXE every time
* servers with oddball Broadcom NICs where chainloading iPXE doesn't work at all
* servers that sit at the BIOS screen for twenty minutes unless you pull out all the U.2 NVMe devices, then they boot OK. Maybe a firmware update will fix it!
* firmware updates that don't install properly through the BMC
* firmware updates that don't _show_ they're installed properly until the BIOS boots completely and can report the new version through apparently some kind of HTTP request on an internal USB NIC to the BMC, even though the BMC has control of the SPI flash and thus is lying to you until that reboot occurs
* BMCs that just stop working until you remove power at the wall from the whole system
* IPMI serial over LAN redirection that drops about 4% of output characters but not in a predictable way so copying and pasting, say, a serial number has be done several times to be sure you got the whole thing
* an interrupt controller in a HP system that doesn't emulate fixed interrupts correctly, and so eventually after some random number of millions of interrupts the lines are just stuck on until you power cycle the system
That's just stuff that comes to mind at the moment. There's literally no way to compose a reliable automated production system on this ridiculous tower of packing peanuts. In contrast, in the lab, I can pretty much just ask an Oxide machine to replace the contents of the SPI ROM and the M.2 storage device and power cycle it and it does what it's told. There are comparatively few moving parts and we have the source to almost all of them.
Edit: this board uses DDR4, not DDR5.
Edit: Yes, I believe he says they used the AMD firmware for the PSP (Platform Security Processor).
Edit2: This post may actually be incorrect. Please go watch the talk. I'm not sure anymore.
I have been waiting for someone to find a security vulnerability in one of these cores.
The question after your talk implied that DIMM training was still being done by non-Oxide software.
More generally, we have implemented and opened everything we can; there still remain opaque bits like the PSP, as well as some smaller bits scattered through the machine (e.g., SSD firmware, MCU boot ROMs, VR firmware, etc.). We have endeavored to make as open a system as possible within the constraint of not making our own silicon. And while we haven't talked about it publicly, we will also open our schematics when we ship the rack, allowing everyone to see every component in the BOM. While we do have some (necessary) proprietary blobs in the system, we want to at least be transparant about where they are!
Is changing that on your roadmap?
The essence is that the signals are so high-speed, ie each bit takes a very short time, that the physical distances between DIMM modules and DRAM modules on a DIMM start to matter and has to be compensated for so that all relevant signals arrive at the same time at a given DRAM module.
[1]: https://www.systemverilog.io/ddr4-initialization-and-calibra...
if it weren't for linux's dependence on the bios pci and memory probes, you could really cut out all that crap. you need to program the memory controllers and bring in the kernel from storage.
(Outside of the process of getting into the kernel. Most x86 users are going to be booting off of storage that's behind PCIe somehow.)
Edit - for clarity, I mean calling back into firmware after boot for PCIe functionality.
I would really like to know if my x86 'linux PC', is actually running another 'hypervisor' OS that runs Linux - it seems like a recipe for security vulnerabilities.
If so, there are a lot of Qns :
- what OS, is it up to date ?
- can this OS be communicated with from the network ?
- on which chips does it run ?
- can it be re-flashed / upgraded / replaced ?
- can it interrupt/schedule my normal os ?
- how much CPU/power does it use ?
I would certainly trust an Oxide supplied (Rust) bare metal open-source low-level OS to host linux vms on my dev machine, than say, a totally opaque binary blob that the US government has forbidden xyz company from talking about.. just to speculate wildly.
I also think Oxide has wider market that just the server space - eg. one has to do all sorts of shenanigans to get a core freed up so that you can run timing/latency sensitive apps, without getting interrupted by linux threads doing noisy housekeeping on each core.
There's not so much a "hypervisor" OS, but instead a congealed set of many different OSes, some realtime OSes, some possibly old Linux variants, some possibly closed source proprietary one-off OSes. I suggest taking a look at the talk Bryan mentioned: https://www.youtube.com/watch?v=36myc8wQhLo
In Oxide this doesn't happen, the Pico thingy boots into their OS and that's it. There is no in-between step. The OS then simple loads the additional things it needs. It never hands of control to anther kernel.
At least this is how I understand it.
I'm not super familiar with coreboot, but isn't that step kinda optional? I mean could you start booting up userland directly too?
I wonder if there's some confusion because LinuxBoot is being talked about relative to Oxide. LinuxBoot isn't trying to do that.
It was originally a project called "LinuxBIOS" at Los Alamos National Labs to get their supercomputer to boot up in a reasonable amount of time. Once the team started down the path of "rip out the legacy BIOS" they discovered that a lot of things become simpler.
LinuxBoot was written with the goal of booting up the machine to GRUB, like this:
(CPU Reset) > LinuxBIOS > GRUB > Linux
See the description of this video (though the video is worth the watch): https://vimeo.com/724454408 "Why Linux? Because firmware always evolves to become an operating system. Rather than wait for evolution to take its course, LANL decided to save some time and use Linux as the BIOS: hence LinuxBIOS."
See also https://lwn.net/Articles/10590/
-----
And the answer to your question: "could you start booting up userland directly?" I think if the LinuxBoot authors were around they would mention something about how constrained the on-board flash chip is (SPI Flash). There's room for LinuxBoot and maybe GRUB, but there is not room for all the drivers needed to get to userland.
(CPU Reset) > Coreboot > LinuxBoot > GRUB (or whatever) > Linux
Coreboot: https://www.coreboot.org/
LinuxBoot: https://www.linuxboot.org/
LinuxBIOS was renamed Coreboot for marketing reasons.
LinuxBoot is much newer concept.
It's always been a worry that if more people can quite shakespeare than do long division or understand a car engine then we will have "uninformed" decisions.
I am dubious about that - I think of elections are meaningful, the populace takes them seriously and self informs to a level they are happy with (!) but anyway I like the idea that some of the Linux Kernel maybe in peoples heads enough to pop up in middle age
https://www.poetryfoundation.org/poems/56968/speech-friends-...
If the hardware is really a smaller CPU on the other side of a bus or HCI, and what's exposed to the CPU is really a remote-RAM-loading-and-communication interface, that's fine. That's not host CPU firmware, that's device CPU firmware and while that sucks for it to be under NDA/undocumented, at least it's mostly in its own little world. The registers/process needed to setup and talk to that remote embedded CPU should be fully documented and available to anyone.
ACPI is a travesty for enabling this hiding of specific hardware interfaces-often tied to things you need to have your laptop be useful like battery controllers and fans. SMM is a travesty for giving it a place to live.
I watched all the talk, and it seems to be centered around the fact that opaque, vendor-specific blobs that run on hidden cores are a security weakness.
I agree with that, but to be fair, what segment of the market actually cares enough about this to pay oxide money?
There may be a business case in there, but the talk certainly doesn't explain what that is.
If (let’s be real, when: nothing is perfect…) problems in our system are found, we can fix them.
There’s other reasons too. But imho that’s the big one.
Also he mentions more then security.
But the need the BIOS offers lives after it,
and proprietary systems are interred within its bones.As I understand it, the proposal is that every bit of software running on a device that is currently considered "firmware" ought to be in the OS instead. What does the story of how we get from here to there look like?
1. We convince manufacturers that it would be a great idea to release thorough documentation for all of their hardware products, and that way open source kernel developers can write their own firmware and merge it into open source kernels. Bryan gestures in this direction several times throughout the talk, claiming that this would be good for the hardware manufacturers because it would enable us to by more of their products. But ... no one's really convinced this is going to work, right? The hardware companies don't want to release documentation for the exact same reason they don't want to open source their hardware; it's a barrier (however small) against leaking trade secrets.
2. We focus our efforts on small companies like Oxide building integrated, top-to-bottom systems designed to run without firmware. This is great because it enables BIOS-less system design from the ground up and can be every bit as open source as we want it to be. But this means waiting and hoping that a tiny number of companies manage to reverse engineer the chips (like the AMD processors discussed in the presentation), which probably means running years behind and an extremely limited selection of hardware. This is not a solution that is going to deliver my next laptop, let alone my grandma's next laptop.
3. We convince manufacturers that EFI is a broken, sucky, insecure mess and include and let them help lead a process designed to replace it. This could maybe happen, we did get rid of BIOS (in favor of EFI) after all, but what is the end result likely to look like? It looks like binary blobs running unknown code necessarily tainting nearly every Linux system under the sun. And that's if they don't just decide to integrate with Microsoft and ignore Linux completely.
That's the thing about isolation. It has problems, as this talk discusses, but it also means that (putting aside a great number of bugs) an OS like Linux can exist without needing to reverse engineer firmware for the enormous amount of hardware it runs on. It's great to be able to run an OS with few-to-no blobs active, e.g. with open source Wi-Fi and graphics drivers. Closed firmware is in theory a security nightmare, but in practice it's not that often that anyone managed to exploit these vulnerabilities. Can you imagine having to run closed source Wi-Fi firmware in the Linux Ring 0?
I’m interested to see the progress of open source firmware now.
CPU boots, PC sets to zero, starts reading instructions from ROM, optionally paging out the ROM if we really need to recover that memory window. I get that x86 is a bit messier because you have optional bioses that get run, and then you read and run the first page of the storage device, but .. man have they made life difficult since I last paid attention.
(Also, user name checks out.)