ronald g. minnich

The LinuxBIOS project began at Los Alamos National Lab in Summer 1999, as the first piece of the Clustermatic HPC software stack. 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.

A lot of the early history is contained in mailing lists and web pages, now lost. Thanks to git and the WayBack machine, some of the details can be found. This talk will present details from the very early days to the present of the project itself, and the meta-issues of how the project evolved, how the vendors almost killed it, how Google saved it, and how it is thriving: there are now more coreboot laptops than Mac laptops, for example.

Oreboot = Coreboot without C. Oreboot is a fully open-source power-on-reset and romstage firmware written in Rust. By design, the firmware requires all support packages (such as memory init) to be open-source. Currently, Oreboot can boot an AST2500 ARM BMC to Linux with a u-bmc user-mode.

Oreboot rethinks the firmware driver models. Each driver is distilled to four basic functions: init, pread, pwrite and shutdown. This interface allows us to make convenient higher-level drivers such as a "union driver" which duplicates a single write operation to multiple drivers. This makes consoles which have multiple underlying UART drivers elegant.

By using the Rust programming language, Oreboot has a leg-up in terms of security and reliability compared to contemporary firmware written in C or assembly. Rust's borrow-checker ensures pointers are not used after being freed and proves that coroutines are thread-safe at compile time.

In this talk, we will also present a short overview of the basics of Rust, how our driver model incorporates coroutines and the bootflow of Oreboot.

The coreboot ramstage was created because Linux could not correctly a PCI bus in
1999.
Since then, the ramstage has grown in complexity and, in conjunction with depth
charge, is well on the way to becoming a small kernel.
At the 2018 OSFC Minnich[?] suggested that we might consider making the ramstage optional, since he had found that some im some ports (RISCV) and some situations
(linuxboot) it was no longer needed, and it was a significant burden in terms of boot speed
and code.
Intel and Google have been studying this idea. In this talk we discuss our exploration
into making the ramstage optional. There is a significant boot time performance improvement.

Do you want to have all the tools on your linuxboot system that you have on your desktop, but you can't get them to fit in your tiny flash part? Do you want all your desktop files visible on your linuxboot system, but just remembered there's no disk on your linuxboot system? Are you tired of using scp or wget to move files around? Do you want to run emacs or vim on the linuxboot machine, but know they can't ever fit? What about zsh? How about being able to run commands on your linuxboot machine and have the output appear on your home file system? You say you'd like to make this all work without having to ask your Sysadmin From Hell to Do Magic to your desktop?

Your search is over: cpu is here to answer all your usability needs.

CPU is a go implementation of Plan 9's cpu command. It uses the go ssh package, so all your communications are as secure as ssh. It can be started from /sbin/init or even replace /sbin/init, so you have teeny tiny flash footprint. You can see the code at github.com:u-root/cpu. It's also small: less than 20 files, including tests.

CPU runs as both a client (on your desktop) and an ssh server (on your linuxboot machine). On your desktop, it needs no special privilege. On the linuxboot system, it needs only fusermount. On the remote machine, it mounts a FUSE server into a process private name space at important places like /home/$USER, /bin, and so on. It implements remote file access by relaying FUSE requests via gorpc to a server embedded in the cpu command. The desktop command services those requests; you don't need to run a special external server.

CPU will change your life. You can forget about moving files via scp: once you 'cpu in', the /home directory on your linuxboot node is your home directory. You can cd ~ and see all your files. You can pick any shell you want, since the shell binary comes from your desktop, not flash. You don't have to worry about fitting zsh into flash ever again!