OSFC 2018 - coreboot rompayload | Ron Minnich

Summary

In this tech talk, the speaker delves into the concept of RAM payloads in firmware, contrasting them with the traditional ROM stage. They recount the history of Linux BIOS and the evolution of the RAM stage, which was initially designed to overcome limitations in Linux. The speaker argues for the potential redundancy of the RAM stage in modern systems, especially with advancements in Linux's capabilities. They also discuss the move towards eliminating runtime firmware services due to trust issues and advocate for a simplified boot process, demonstrating a live test of a RAM payload in coreboot, highlighting its efficiency and potential for future boot systems.

Takeaways

• 😀 The speaker experimented with a 'random payload' approach, inspired by Trammell's picture of Vincent, which involves loading a payload directly from the ROM stage instead of using a RAM stage.
• 📝 The speaker emphasized the importance of having an outline for a talk, but also the need to go beyond a basic outline for better informativeness.
• 🔍 The RAM stage's function is to discover, allocate, configure, and enable resources before booting, and it has been evolving since 2007 with the introduction of SMM (System Management Mode).
• 🚫 The speaker expressed concerns about the trustworthiness of firmware, advocating for an 'air gap' approach where the firmware runs and then never communicates back, to avoid potential security issues.
• 🛠️ The speaker discussed the history and evolution of the ROM stage and RAM stage, including the initial challenges with Linux and the development of the device model in coreboot.
• 🔧 The speaker shared personal anecdotes about working with Linux BIOS and the evolution of the Linux kernel, including issues with PCI device enabling and the incorporation of PCI enumeration code.
• 🔄 The speaker questioned the necessity of the RAM stage given the growing capabilities of Linux, suggesting that in some cases, the RAM stage might be redundant.
• 💡 The idea of a RAM payload was presented as a potential simplification of the boot process, where the payload is loaded directly from ROM without the need for a RAM stage.
• 🔗 The speaker touched on the complexities and potential security risks of UEFI (Unified Extensible Firmware Interface) and the desire to move towards a more streamlined boot process.
• 🛑 The speaker critiqued the current signing models in firmware, arguing for more user control over their machines and against vendor lock-in.
• 🔄 The speaker concluded with a demo of the RAM payload in action, showing its practical application and performance, and opened the floor for questions and further discussion.

Q & A

What is the main topic of the speaker's presentation?

The speaker is discussing the concept and implications of RAM payloads in the context of firmware and operating systems, particularly focusing on their evolution, necessity, and potential redundancy with advancements in technology.

What does the speaker mean by 'random payload'?

A 'random payload' in this context refers to a payload loaded from the ROM stage instead of loading a RAM stage, which is a departure from the traditional method of loading payloads for booting up systems.

What is the purpose of the RAM stage according to the speaker?

The RAM stage is designed to discover, allocate, configure, and enable resources before booting the system. It also serves as a means of communicating this information to the payload.

Why did the speaker attempt to implement a RAM payload?

The speaker was inspired by Trammell's picture of Vincent and wanted to explore whether the RAM payload method could work effectively, although it didn't work as intended due to banding issues.

What is the speaker's view on the necessity of the RAM stage in modern systems?

The speaker questions the necessity of the RAM stage, suggesting that with the growth in capabilities of operating systems like Linux, the functions traditionally performed by the RAM stage might be redundant.

What is the speaker's stance on the use of SMM (System Management Mode)?

The speaker expresses a negative view of SMM, stating that it was considered a bad idea even in the early 2000s and that they would prefer not to have it running on systems due to security concerns.

What is the speaker's opinion on the current state of firmware in systems?

The speaker criticizes the current state of firmware, describing it as a large, complex operating system that often contains vulnerabilities and is a source of vendor lock-in.

What is the speaker's suggestion for handling firmware updates?

The speaker suggests that instead of relying on firmware updates that require reflashing, systems should allow for the kernel to supply M mode code, which can be updated simply by rebooting.

What is the 'air gap' concept mentioned by the speaker?

The 'air gap' concept refers to a design choice where components are loaded by other components without any communication back, which is intended to prevent trust issues with untrusted firmware.

What is the speaker's view on the future of firmware and operating system interactions?

The speaker advocates for a future where operating systems have more control over their environment, including the ability to supply their own M mode code, rather than relying on potentially untrustworthy firmware.

What is the speaker's final recommendation regarding the RAM stage?

The speaker recommends revisiting the necessity of the RAM stage in light of modern capabilities of operating systems and suggests that direct payload loading from the ROM stage could be a viable alternative.

Outlines

00:00

🔧 Experimenting with RAM Payloads and BIOS Limitations

The speaker begins by expressing their initial attempt to emulate Trammell's work on recursion, which didn't go as planned due to banding issues. They discuss the importance of having an outline for a talk and proceed to explain the concept of a RAM payload, contrasting it with the traditional ROM stage. The speaker clarifies that a RAM payload is loaded directly from the ROM stage, bypassing the usual RAM stage process. They delve into the history and evolution of the RAM stage, its purpose in discovering and allocating resources before booting, and the introduction of untimed firmware SMM. The speaker also reflects on the early days of Linux BIOS and the challenges faced in integrating Linux as a RAM stage, including issues with SDRAM and PCI device enabling.

05:00

🛠️ The Evolution of Linux and the RAM Stage Intersection

This paragraph delves into the evolution of both Linux and the RAM stage, questioning the necessity of the RAM stage given Linux's growing capabilities. The speaker discusses the early risk ports that lacked a RAM stage and expresses concern over the direction of the RISC-V community, which seems to be expanding the RAM stage based on x86 models. They argue against blindly following x86 practices and emphasize the need to critically assess the role of the RAM stage in different systems. The speaker also touches on the desire to move away from firmware services at runtime due to trust issues and the inefficiencies they introduce.

10:03

🛡️ Trust Issues with Firmware and the Case for Kernel-Controlled M Mode

The speaker addresses the trustworthiness of firmware, advocating for control of the machine by its owner. They criticize the current model where vendor keys are fused and immutable, creating a dependency on OEMs for updates. The speaker prefers the Chromebook model, where the owner has the ability to change keys. They also discuss the inefficiencies and potential for bugs in firmware, suggesting that the kernel should supply M mode code instead of relying on firmware, allowing for easier updates and optimizations.

15:04

🔄 The Challenge of Firmware as a Service Layer and the RAM Payload

The speaker continues to critique the reliance on firmware, likening it to a complex operating system with potential for exploits and inefficiencies. They recount the history of firmware's growth and its role in vendor lock-in, expressing a preference for a model where the kernel supplies M mode code, allowing for easier updates and less dependency on firmware. The speaker also discusses the concept of an air gap, where the system is designed to not trust firmware, and the importance of this in avoiding firmware-related issues.

20:06

🚀 Demonstrating RAM Payloads and the Future of Coreboot

The speaker presents a live demonstration of a RAM payload in Coreboot, highlighting the process and its outcomes. They discuss the changes made to the payload, including the addition of 'Linux check' to ensure a smooth transition for Linux. The speaker also addresses the issues with the ROM stage in QEMU and the modifications made to the boot process. They conclude by expressing optimism about the potential of RAM payloads in Coreboot and other architectures, including UEFI.

25:08

🤝 Seeking Collaboration and Input on Coreboot Development

In the final paragraph, the speaker opens the floor for questions and discusses the ongoing work with RAM payloads and Coreboot. They express a desire for collaboration, particularly for testing on real boards and code reviews. The speaker also shares their thoughts on the potential of RAM payloads in the context of UEFI and the importance of avoiding reliance on firmware services. They invite others to contribute to the project and engage in discussions about the future of firmware and boot processes.

Keywords

💡ROM stage

ROM stage refers to the Read-Only Memory stage, which is the initial stage of a computer's boot process where the system's firmware begins execution. In the context of the video, the ROM stage is crucial for starting the boot process and can be used to load a payload directly, bypassing the need for a RAM stage in some cases. The script discusses experimenting with the ROM stage to load Linux directly, which is a departure from the traditional use of the ROM stage to load a RAM stage.

💡RAM stage

RAM stage is the phase in a computer's boot process where the system's firmware transitions from the ROM stage and begins to execute code from Random Access Memory. It is designed to discover, allocate, configure, and enable resources before the operating system boots. The video's theme revolves around questioning the necessity of the RAM stage, especially when the capabilities of modern operating systems like Linux can overlap with those of the RAM stage.

💡Payload

In the script, a payload refers to a piece of software that is loaded during the boot process. Traditionally, the ROM stage loads a payload into RAM, which then takes over the boot process. The video discusses an alternative approach where the payload is loaded directly from the ROM stage, bypassing the RAM stage, which can simplify the boot process and reduce reliance on firmware.

💡Firmware

Firmware is the low-level software that controls a computer's hardware during the boot process and other critical functions. The video discusses the limitations and potential security risks associated with firmware, advocating for a reduction in reliance on firmware services post-boot and a move towards more direct control by the operating system, such as Linux.

💡UEFI

UEFI, or Unified Extensible Firmware Interface, is a modern firmware interface that replaces the traditional BIOS. It is designed to provide more features and security compared to older systems. The script mentions UEFI in the context of moving away from binary blobs and towards a cleaner boot process, aiming to simplify the transition from firmware to the operating system.

💡Coreboot

Coreboot is an open-source firmware project aimed at replacing proprietary BIOS/UEFI firmware with a lightweight and customizable alternative. The video discusses experiments and developments within the coreboot project, particularly around the concept of RAM payloads and the potential for direct payload loading from the ROM stage.

💡Linux

Linux is an open-source operating system kernel that is widely used in various computing environments. The video discusses the evolution of Linux and its capabilities, which have grown to the point where it can potentially perform some of the tasks traditionally handled by the RAM stage, leading to a reevaluation of the necessity of the RAM stage in the boot process.

💡SMM

SMM, or System Management Mode, is a protected mode of operation in x86 processors that allows for out-of-band management of the system. The script mentions SMM as a feature that has been historically included in firmware but is now being questioned for its necessity and security implications, with the speaker advocating for its removal or reduction in modern systems.

💡ACPI

ACPI, or Advanced Configuration and Power Interface, is a standard that defines power and configuration management interfaces for computers. The video mentions ACPI in the context of its potential as an exploit vector and the historical reluctance to integrate it with Linux BIOS, reflecting concerns about security and complexity.

💡Self-loader

A self-loader in the context of the video refers to a mechanism within the ROM or RAM stage that is capable of loading the next stage of the boot process without external assistance. The script discusses the implementation of a self-loader in the ROM stage, which simplifies the boot process and reduces dependencies.

💡Init Ram FS

Init Ram FS, or Initial RAM File System, is a temporary root file system that is loaded into memory during the boot process. The video discusses the potential for eliminating the need for an Init Ram FS by loading the operating system directly from the ROM stage, which is part of the broader theme of streamlining the boot process.

Highlights

Introduction to the concept of RAM payload and its evolution over time in firmware.

Explanation of the original purpose of the RAM stage in firmware.

Discussion on the implementation of untimed firmware SMM or S3 Linux files since 2007.

The speaker's personal experience with the early days of Linux BIOS and the challenges faced.

Historical context of the Linux kernel size compared to the average binary size on GitHub.

The attempt to use Linux as the RAM stage in 1999 and the issues encountered.

The evolution of the device model in Linux and its relation to the RAM stage.

Concerns about the growth of the RAM stage in the RISC-V community and its potential pitfalls.

The idea of eliminating the RAM stage and transitioning directly to the payload.

The current state of UEFI and the desire to streamline the boot process.

The concept of an 'air gap' in firmware to prevent trust issues with firmware.

Critique of the current model of firmware signing and the need for change.

The importance of having control over the machine one has paid for.

The speaker's perspective on the inefficiency and risks associated with firmware.

The proposal to let the Linux kernel supply M mode code instead of firmware.

The potential for RAM payloads to simplify the boot process and reduce reliance on firmware.

The demo of the RAM payload in action and its performance comparison with the standard RAM stage.

Open invitation for collaboration and testing of the RAM payload concept on various boards.

Transcripts

[Music]

give it up for a minute

[Applause]

so I got a little jealous of trammels

picture of Vincent so I was trying her

to this recursion thing and it didn't

quite work as you can see with the

banding yeah so anyway Ram payloads so

they always tell you if you do a talk

you need to have an outline so I did an

outline there so and then I thought

that's not very very informative so you

know I did a slightly more of an outline

so I'm gonna talk about what a Ram

payload is and why you would do it and

how it is done so I am NOT trying to

claim here that this is something you

would do on every platform mainly I'm

trying to say it's something that might

be useful on some platforms so what's

the random payload I mean it's kind of

simple it's just a payload loaded from

the ROM stage instead of loading a Ram

stage you just load the payload from the

rom stage and then that begs the

question because well what is a ram

stage and a bunch of you in here know

more about what it is than I do but I'm

just gonna do my simple definition the

function of the RAM stage is to discover

allocate configure and enable resources

roughly before booting I left one thing

out have some means of communicating the

information to the payload it can and

this is more recent right so the first

eight years this wasn't a thing but

since 2007 or so it's been a thing which

is implementer untimed firmware SMM or

s3 Linux files would speak this began as

originally didn't do that because it ran

on supercomputers and I run on

supercomputers in places that we

absolutely did not ever want to have SMM

running I think even as early as 2000 we

kind of knew SMM was a very bad thing to

put it lightly a the RAM stage is small

in some systems and large on others and

so then you know some people say to me

sometimes oh wait a minute Linux does

that right

next us all that discover blah blah blah

stuff so why aren't you doing it with

Linux and that kind of gets back to the

beginning and we actually never planned

on a ramp stage in the beginning in the

beginning actually Linux was the thing

we loaded so here's the original ROM

stage for Linux BIOS which was actually

completely wrong because between the

time I stopped working with PCI card

design and I got back in the pcs again

this thing called SDRAM happened which

you know I had not a clue about so for

what it's worth when I started this

project I didn't have the faintest idea

what I was doing and it somehow worked

out so anyway so that's the first

totally ridiculous rom stage that didn't

work but you know okay fine that's the

wrong stage let's pretend we got SDRAM

working why don't we do Linux is the RAM

stage in the first place well it

actually turns out we did in 1999 I did

it with Linux 2.2 didn't work get into

that in a second interesting thing I

clicked looked at all the binaries so

the FS Peas on github and the average

the 450k roughly which is bigger than

the Linux kernel that we were putting in

flash back then kind of a surprise

so here's the problem I kind of stumbled

my way through the SDRAM in it and

finally got that working and stumbled my

way through a bunch of early linux

startup and now I plugged in and ie the

IDE device and I got this far and then

it said device disabled BIOS and I

thought I can't be right I am the BIOS

what did I do that I didn't know about

did I kick myself in the back or

something and and the answer was no we

didn't do something behind her back we

failed to do something and Linux back

then interpreted not enabled as disabled

in critical places so and here's the

critical place in tune I to ID PCI type

see there's this loop across the base

address registers and if any one of them

was 0 would just say oh dear me the BIOS

has just disabled the IDE PCI device

which of course we haven't done but we

hadn't enabled it and then it all just

you know it went south at that point so

Linux 2.2 couldn't do it in 2000 and so

I kind of we were really staring to

options in the face

one day option was fixed Linux right fix

Linux is PCI and probing and all that

stuff to work correctly when there

wasn't a BIOS I kind of ping some

friends so binding the Linux community

and they kind of came back with oh

you're just weird so there's no need to

fix this because it works for us you're

the only person and it was literally

true I was the only person on the world

with that problem but you know

nevertheless I was having it and in 1998

I tried to get the ninety subsystem into

Linux and that took eight years and I

didn't know that in 1999 but they

weren't quite as open as they are today

and remember this is free get free bit

get keep bit keeper right this is kind

of like I think there were still

shuffling tar files around I'm not sure

so the second option was fix Linux files

and I went was Plan B I grabbed the

Linux file Linux PCI enumeration code

and jammed it into Linux and things kind

of worked and that became the ROM stage

and the thing we know as a device model

came in kind of envy v2 so well the work

on Linux files started in the second

millennium announced the third

millennium so now we've been around for

like a millennium it seems like a good

time to think this through a little and

and you know the RAM stage has grown

over time from this simple PCI

configurator to a lot more stuff but

Linux has similarly grown in in

capability and they can do a lot more of

what the RAM stage does so the question

is there you can think of an

intersection pointing capabilities

between what Linux knows how to do it

the RAM stage does and a question is you

know do we need the RAM stage it's the

intersection of capabilities at a point

where Linux could just do what the rain

stage does today and part of what drove

this is the FIR early risk five ports

there was no RAM stage I mean the only

thing the RAM stage showed in the

earlier wrist fight for its is loads

payload and I get a little worried

sometimes because I see the risk five

RAM stage and I got to talk to Jonathan

and Phillip about this but I see things

growing in a risk five RAM stage almost

because they're looking at the x86 as a

model and that's not really convincing

reason to do that right so I kind of

worry a little bit about what I see

happening because I saw this happen in a

risk five community well if the x86

does this we should do that so the x86

has SMM well we'd better extend the

privilege mode so we can make sure we

can do a thing like s mm so you know

sort of jumping into the mud pond there

which is not always something you want

to do and further in a lot of cases we

don't want the things the RAM stage can

do for us we don't want s mm we don't

want s3 resume and we don't want to run

times services at all on a lot of

assistants we don't need the RAM stage

to enumerate resources they're simple

and hard-coded or they're PCI and we

know how to enumerate PCI and you know

SMP setup actually in the earliest days

of Linux BIOS we did it in a kernel we

did know SMP setup in Linux files until

about I don't know a 2001 or two when we

had to deal with the k7 which had a very

odd style of SMP setup and we have other

ways to provision things like API so you

know if you look at the RAM stage a lot

of the RAM stage is kind of there in

some places arguably to support other

parts of the RAM stage so that that's

kind of the reason for looking at this

so can we go right through the payload I

did the experiment at the coreboot

conference in Denver in 2015 and kind of

convince myself that well Linux and

Harvey actually could be loaded directly

from the ROM stage the code wasn't great

but it did the job and convinced me and

this is actually what we're hoping to do

in UEFI so here's UEFI today that's a

lot of binary blobs right and and and

there's scary stuff like there's this

stuff right this happens when Linux is

running what does it do the OS present a

fact what does that do

I don't know and there's just a lot of

stuff in there that's read right for me

blood-red and this is what we're working

to we're not there but if we look at the

SCC and PCI footprint in ROM it's about

10% and what we want to do is go right

from that last step which is the board

in it right into Linux and flash and you

saw your route this morning we won't

have an init Ram FS containing you route

with a net food or local boot and if we

desperately need to run some UEFI driver

we're gonna run that out of Linux so the

big big red mess in the middle is gone

completely

and further we're doing we're putting in

this concept of this air gap okay

any idea is like we used to do in Linux

BIOS that thing loads that thing and

this thing never talks back and the

reason is simple we don't trust firmware

so that's a reasonable thing to not

trust right they still in the last two

years so the runtime is gone the OS

president app is gone and this thing

just runs and that's what we're trying

to work to so it's simple rule if you

don't underwear then you'll be owned by

the firmware and we'd rather not be

owned so by the way little digression

the Linux BIOS Linux boot community is

pretty big as Ryan showed we've had a

lot of discussions about signing now

we're stumbling right we're getting

right close to the edge of my lack of

understanding of some of these things

but basically as I understand that the

current model is that vendor keys get

fused in to these fuses and then you can

lock out any further attempts to change

them that's just got to stop so that's

got to get fixed the current model is

just not acceptable and here's the

simple reason one simple reason let's

just say the odium sets the fuses and

then here's a customer let's just i'll

pick on facebook facebook is a customer

if they want to do anything and get it

signed they have to go back to the OEM

okay fine now facebook sells nodes to

john reese company for him to resell

he's got to kind of go back around

facebook to this company then this

company buys them from john murray

they've got to go back to that company

if they ever change the firmware this is

just not an acceptable situation this is

one of those cases where I think chrome

really completely got it right you get a

Chromebook you want to change the keys

you change the keys right cuz it's your

you are the owner so I'm not even

arguing here for open up all the source

give us all the source GPL your source

I'm really just arguing for give us

control of the machine we paid money for

that's a simple argument so if anybody's

interested in having this discussion

Friday or Saturday May

we can sit down and talk about it but

this has really got to change another

thing that we keep getting into for the

last 18 months on this project we've got

to get from a point where we're doing

docks by reverse engineering to docks

and you may hear that theme a few more

times in the next day anyway that air

cough I mentioned is essential because

it breaks this connection between you

and the firm where you don't trust now

it's not that people are bad or people

are dumb it's that people make mistakes

we all make mistakes right I make lots

of mistakes and if you have a model

where someone is going to create a blob

and that blob will be bug free forever

and they're gonna put it in this thing

and are gonna sign it and you are stuck

with that blob it's not a workable model

right and and if that is the model and

that is the model today then your best

decision you can make is simply not to

trust that once you're booted and that

was the model from Linux files right we

locked out SMN we heard a lot of stuff

about it was impossible to create a

server platform that didn't have SMM

Linux Network shipped well over a

hundred thousand nodes with no SMM they

worked fine so um you know in 2000 the

plan was no SMM and actually no acti

because we knew a guy from AMD who had

resigned from the ACPI committee because

he told us it was just the exploit

heaven and he didn't want anything to do

with it

we're not sure what to do about acne but

oh well we did keep the air-gap for the

first eight years of linux fast until

laptops and you know i think we all know

the story there if you're gonna do a

laptop you're gonna do power management

and the only model you've got there is

SMM and act ii but what is it BIOS and I

got to thinking about this and part of

the reason is almost embarrassing I

wrote my first firmware 40 years ago

this year and it gives you some

perspective so in 75 Garry killed well

he's kind of the guy who invented the

term BIOS for CPM you know you let it

seep yet from a floppy and then in your

1 kilo byte a EEPROM on your inside or

out there right you had this little

library any idea is CPM set the rules

right

CPM said if you're gonna run me

you're gonna implement this to our

specification so CPM ruled the roost

right they they defined what that

interface was then comes 1980 and it got

a little weird because IBM released the

PC and they actually released the source

code to the BIOS but it was copyrighted

but but this weird thing happened that

it flipped right it's like the boat

flipped over all of a sudden the thing

that set the rules was the BIOS not some

kernel and if that's the initial

condition to where we are today where

BIOS is set rules and we have to conform

to those rules it wasn't that way in the

first couple of years so where we are

today is the firmware it's a 81 92 times

larger it's a hardware adaptation layer

it's a vendor lock-in tool I mean you

can take your choice of these I tend to

pick them all it's a complex operating

system it's a large collection to build

in Valle 'nor abilities and exploits

it's a very inefficient way to access to

services and in my opinion is something

and everyone to use once you're booted

that's the reason for what we're doing

here and yet it keeps recurring so the

risk 5 model is we've got the super end

user modes and there's this thing called

machine mode and machine mode is

provided by the firmware vendor ok and

you know do we have to do that actually

we don't in the risk 5 this the one

privileged mode the kernel could load M

mode but we're all kind of working

toward this model and you can see the

patch is coming into coreboot where the

firmware is going to provide the M mode

and it's going to lock out the kernel

from changing it that's called security

and some planet or universe but it

really doesn't have to be that way it's

just the way we think about it because

that's how we think about everything

right firmware is permanent it has a

higher privilege in anything it's the

route of trust and the only problem with

all that is this wrong because we can't

trust it so we have an untrustable route

of trust now I'm talking to one risk 5

company that's working with someone I

know in do-e they're not going to do

that in their in their risk 5

implementation the M mode code will be

supplied by the kernel not the firmware

so what's wrong with em mode firmware

libraries well why would you trust it

right it's gonna be written by the same

people you know at these vendors off

somewhere I'm not playing fingers that

even the chipset guys somebody is gonna

hack this thing up because we're trying

to get a board out in schedule and

they're gonna insert bugs that's what

keeps happening so why on earth would

you want to trust em mode stuff supplied

by the kernel like I mean that firmware

I can't think of a reason you know and

how and when do you update if you if you

have a bug in M mode you've got to

reflash the firmware and all your

machines if you supply the end mode with

the kernel you reboot and you have the

fixed end mode code so you know if you

have an M mode security fix and the

kernel supplies the code you reboot done

you've you've updated your M mode code

you didn't have to reflash for formants

you know what's the API for these things

it's always maximally paranoid okay if

you write firmware that's going to be

called by something you'd better assume

the thing calling you is bug-ridden you

can't trust it at all okay so you've got

to do this a maximal saving of state to

make sure that you don't get hurt and

you know I've been here before on the

IBM Blue Gene one of the last series in

order to sort of preserve this IP layer

they created this giant blob of a

firmware if you wanted to send a packet

on the IBM Blue Gene Taurus the idea was

let's call this thing in firmware to

send the packet for us okay well when

you called that firmware on Blue Gene

headed to a full TLB and cache flush and

change the page table route so it was

incredibly horrendously inefficient and

you know all the guys who did kernels on

Blue Gene including me we just ignored

the firmware and we wrote our own code

to send packets on the torus because we

couldn't take that performance hit so

you know I'm just not a big fan of you

know firmware I call because it hasn't

proved to really be a great idea and

where is on risk 5 if the kernel is the

end mode it can optimize calls to the

end mode code so here's the slightly I I

think this is the thing I expect to get

beat up about kernel should should PI

firmware services they need and this is

kind of building on last year or I was

showing that

a Linux kernel could supply the SMM code

and use it instead of the firmware

supplied code if there's a firmware

service mode in the CPU then let the

kernel supply the code it runs that's

real easy to do on risk 5 most of that

stuff's to find in the core boot arch

directories very easy to add that to

Linux and have Linux set it up and you

know this this policy though act 10

sacks against this tendency people have

like m-mode code or whatever code you

want to call it you know people say oh

we need this extra thing I know we'll

just add another function mo then it

grows without bound that's what we've

seen happen that's why you know BIOS is

on PCs or now eight megabytes of runtime

stuff so I also think it would force a

degree of your strength and what gets

foot into n mode and it would also this

one's important you know this stuff is

always a lock in it's always a chance to

lock you in to a given vendor because

they supply some firmware library and

the equivalent of M mode no one else

supplies and now you've discovered

you're dependent on it and you can't

change vendors anyway back to the RAM

payload that's my rant there's a ram

payload for Concord org the rom stage

loads the RAM payload if that fails goes

directly to the RAM stage that's very

handy for when things go wrong aside I

think we need to I keep running across

calls to run Ram stage that are followed

by a die but Renton Ram stage never

returns or didn't used to because it's

got a die in and if it fails so we've

got some kind of weirdness in the way we

call Ram stage a lot of its historical

and goes back I know some of that code

is 10-15 years old

anyway if the RAM payload works you get

a prompt Brian talked about Linux kernel

and you root this morning that's what

the test I'm doing does which I'm going

to show you in a minute so it changes 13

files

I added into the payload called Linux

check which made my life way way easier

Linux check is is intended to be a

regression test that may grow over time

and all NX check does is grovel just

hunts around the machine looking for

things that might cause trouble for

Linux so it's a nice small piece of code

it makes sure you have a console that

the serial is set up that a number of

memories is in the 8

a table is greater than zero that's

always nice Linux will panicked and

visibly if that is zero so you know

Linux jet gets handy for finding things

that Linux will not tell you have

happened

and the only problem I've found so far

once I got through some of this is that

core boot ROM stage praying at least for

me doesn't actually work in qmu anymore

don't know why yet I added a ramp a load

config bearable in CDF as in Ryan I've

caught a call to run ramp rogue this is

kind of boring stuff and I'm just quick

on a quick run through it in the yard

8250 i/o if config ramp payload is set

then I call your fill lb which adds a

table entry for the serial port and then

in the you know I created this function

run ramp rogue and that changes program

loading todd h one weird thing i added

my own compact boot mem write memory

table because calling the standard one

that runs on the ram staged rings in a

lot of dependencies on tables that we

don't actually create in the rom stage

so it proved to be a lot simpler just to

have a real truncated write memory table

in the source leadcore boot table i just

disabled a few things I enable CBM list

and here's the one that's been a little

controversial since I started doing this

I've got a self loader for the ROM stage

and it actually looks a lot like the

Linux BIOS cv3 self loader it's a lot

simpler than the RAM stage version

because I don't have anything in RAM

more or less right so I just called and

and move it all to memory the push fact

I got is we should only have one self

loader my pushback on the pushback is

self is a data structure format self

loaders walked that data structure

format and take certain actions similar

to elf I don't see a problem with having

to self loaders one being very complex

and one being very simple so we can

argue about that in the next few days

when we're here I'm sure we will but

that's my take on self loaders so that's

it so far what about acti yeah what

about efi we're not sure of that act ii

Trammell's work on heads he actually was

talking about loading a key from a file

in unit ram FS rather than you

one in the firmware because guess what

we don't trust firmware so we're not

quite sure what we want to do a lot acti

it's just there have been issues in

these active tables over the years and

so I I don't think we'll want to quite

do the full air gap with coreboot but

never know so summary is random payloads

were the original Linux files design the

RAM stage was created to cover for these

Linux limitations and they just haven't

proven to be needed in all cases and

this began when I was looking at the

risk 5 and it continued when I was and

then looking at UEFI when we were

throwing away everything after the PGI

and it seemed worth going back and

taking a look at what we do in coreboot

we don't want to use run time firmware

services because we keep getting burned

by them and that then makes the payloads

look more sensible than ever and we're

looking at developing them for a ufi

that's of course just about well

work-in-progress coreboot going to demo

it and you boot on those processor

architectures and I've forgotten I left

off power because this works on power

alright so let me do the demo so this is

qmu you know normal dot rom you know

standard Ram stage with the Linux

payload and as I mentioned this is a

basically this is the kernel that Ryan

was talking about this morning along

with you root as unit ram FS so way we

go

okay now ruff that prompt is the root

shell prompt so you know this this

varies and and I haven't done enough

runs because I'm not a statistician but

it kind of is like in above 5 type

territory most of the time you can

hammer me on my lack of statistical

rigor that's fine and here's the RAM

payload I mean even in queue of you you

can see well same time don't like anyway

generally this seems to be faster and

it's not surprising because no way about

it if you load the RAM if you load the

colonel from the rum stage that's hard

to see it being much slower than loading

the RAM stage from the rum stage and

then loading the colonel from the RAM

stage so it actually works though and

after i po the pci thing we have a

command in your route called pci just

prints the pci bus and you know you can

do stuff like well show me your config

space and the thing i notice here is if

for those of you who really know pci

well if you look at sort of config space

for i don't think i've actually

correctly configured that command

register but it's and I don't think well

I think that might be a bar there I'm

not sure so I'm not entirely convinced

that the PCI configuration is correct

yet but I think it's fairly easy to deal

with that kind of issue yeah so that's

kind of it work in progress I think we

could make this go and I think we can

sort of dispense with what the RAM stage

does and more importantly we're trying

you know I'd kind of actually like this

to be sort of competitive I you're gonna

be surprised to hear me say this with

UEFI boot and one way to get there is is

not run the ramp stage and boy am i I'm

also finishing really early so you're

getting oh five minutes left

oh I'm not finishing early it's time for

questions yeah thank you very much yeah

the round of applause thank you

[Applause]

so it's question-and-answer time so

you're supplying the questions supplying

the answers or so I've heard

what's it who survives questions that's

such a new thing for me here so bright

so what do you need from other users who

are interested in coreboot you know rom

stage do you need tests already yes do

you think it would work on real boards

or would you be interested in tests or

the Theresa I'm glad I'm here is because

of the two-day hackathon I'm hoping

someone comes up to me and says I

brought in x86 with coreboot let's give

it a shot okay

and further yes anyone who wants to jump

in and give me a hand the more we

learned a better right maybe this will

never work mate I'm actually pretty sure

on wrist five it will work very well

depending x86 not sure yet we'll see

but yeah I'd anything anyone wants to do

it love to have the help including code

reviews of course so any more questions

all right okay thanks thank you have

another round of applause for one

[Applause]

[Music]