ronald g. minnich

RunDXERun allows safe execution of UEFI boot applications. It runs these applications in a KVM-based VM, using a Virtual Machine Manager (VMM) written in Go. As the boot applications call UEFI services, they exit the VM and and the RunDXERun VMM handles them. The services themselves are also implemented in Go. RunDXERun is intended to be compiled as part of u-root and used in firmware images. As of October, RunDXERun successfully starts the u-boot EFItest program, and runs one of its tests. RunDXERun in a u-root image increases its size by about 500K (uncompressed) or 145K (xz compressed). This is not much larger than building in a full EDK2. It fits easily in payloads destined for coreboot. The reason to use RunDXERun is for the security it provides. Normally, UEFI boot applications run at the highest privilege level of a machine, as do the boot services. RunDXERun allows running both applications and UEFI services at the lowest privilege level, and the services are implemented in a memory safe language. RunDXERun is similar in spirit to the "safe" ROM support already in coreboot. RunDXERun compiles for both x86 and ARM64; writing the initial port for ARM64 took four hours.

The Open-Source Firmware Foundation has been founded 6 month ago - we like to look back on the founding process, and like to invite guest to talk about workstreams within the OSFF, and the future of open-source firmware. Confirmed Guests: * Philipp and Chris summarize the past year, trying to bring the foundation to live and solving problems along the way. * Alex Matrosov is one of the first individuals leading the security workstream within the Open-Source Firmware Foundation * Bryan Cantrill, Co-Founder of Oxide, refers about open-source firmware and the rising importance of OSF within the industry * and some more.. Join in on 45 minutes of "behind the scenes" of the OSFF and general talks on why OSF is important. We will shim some light on these topics from an industry point-of-view. This session will be moderated by 9elements which will guide you through the discussion.

Other people: Philipp Deppenwiese Christian Walter Fredrik Stromberg Alex Matrosov Bryan Cantrill

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!

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.

Other people: Tan Lean Sheng

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.

Other people: Ryan O'Leary

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.

u-root

I invented the ramstage in late 1999 because Linux could not enumerate PCI correctly. Since then, the ramstage has grown in complexity. On one port (RISC-V) I observed that the ramstage was not really needed. In more recent work on LinuxBoot, we've also found that we don't need the ramstage in some cases. If the romstage could load a payload directly, then we'd save some steps. The romstage on LinuxBIOS V3 could in fact do this, and in this talk I discuss our experiences in restoring rompayloads to coreboot.