[LinuxBIOS] C3 Lightning Talk abstract

[Peter Stuge]

I'm going to C3 and would like to hold a LinuxBIOS Lightning Talk.
See http://events.ccc.de/congress/2006/Lightning_Talks and
http://www.guckes.net/cccc2006/lightning_talks.html

We get five minutes. What do we want to say?

I was thinking: (Please revise this list. :)

* Describe what LinuxBIOS is and does, benefits and use cases off the
excellent wiki welcome page.

* Talk about payloads.

* Mention OLPC. (But what are the important points?)

* Show a demo.

//Peter

[Al Boldi]

Peter Stuge wrote:
> I'm going to C3 and would like to hold a LinuxBIOS Lightning Talk.
> See http://events.ccc.de/congress/2006/Lightning_Talks and
> http://www.guckes.net/cccc2006/lightning_talks.html
>
> We get five minutes. What do we want to say?
>
> I was thinking: (Please revise this list. :)
> Describe what LinuxBIOS is and does,

and does not (i.e: not backward-compatible with 16bit bios calls)
> benefits and use cases off the
> excellent wiki welcome page.
>
> Talk about payloads.
>
> Mention OLPC. (But what are the important points?)
>
> Show a demo.

Thanks!

[Peter Stuge]

On Wed, Dec 06, 2006 at 09:17:24PM +0300, Al Boldi wrote:
> > Describe what LinuxBIOS is and does,
>
> and does not (i.e: not backward-compatible with 16bit bios calls)

Good point, thanks!

Also:

* Talk about all the improvements in v3.

//Peter

[Carl-Daniel Hailfinger]

Peter Stuge wrote:
> Describe what LinuxBIOS is and does, benefits and use cases off the
>
> excellent wiki welcome page.

Since C3 is going to be frequented by security-conscious people and
general interest in tampering with hardware will be high, try this:
* SSH into BIOS for the paranoid
* Authenticated booting
* Using any TPM against the intention of the vendor

Other points:
* Very fast boot process -> for routers it means availability one
  second after switchon
> Mention OLPC. (But what are the important points?)

* BIOS can already use wireless
* Automatic authenticated BIOS updates
* BIOS can be tailored to individual needs (wireless/wired network
  card support, ipv4/ipv6, flat panel/vga...)
* BIOS bugs can be fixed even if upstream is not ready/cooperating
  (not that I would want to suggest that upstream was uncooperative)

Regards,
Carl-Daniel

[Peter Stuge]

Great stuff! Thanks for the input!

On Thu, Dec 07, 2006 at 02:16:47AM +0100, Carl-Daniel Hailfinger wrote:
> Authenticated booting

Have BIOS check payload you mean? Or have payload check rootfs? I
guess they blend into one.
> Using any TPM against the intention of the vendor

By using a payload that does tricks before the TPM starts up?
> > Mention OLPC. (But what are the important points?)
> BIOS can already use wireless

What's it used for?
> Automatic authenticated BIOS updates

Are the details ironed out yet? Is userspace still involved?
> BIOS can be tailored to individual needs (wireless/wired network
> card support, ipv4/ipv6, flat panel/vga...)

Oh yes.

//Peter

[Carl-Daniel Hailfinger]

Peter Stuge wrote:
> Great stuff! Thanks for the input!
>
> On Thu, Dec 07, 2006 at 02:16:47AM +0100, Carl-Daniel Hailfinger wrote:
> > Authenticated booting
>
> Have BIOS check payload you mean? Or have payload check rootfs? I
> guess they blend into one.

Both. But the BIOS checking the payload is IMO key to a secure boot
(if you don't trust the payload, you can't trust any assessment of
rootfs security by the payload).
> > Using any TPM against the intention of the vendor
>
> By using a payload that does tricks before the TPM starts up?

Yes. Some factory BIOSes seem to lock the TPM and/or do other
(for that startup) irrevokable stuff. Using LinuxBIOS gives you
full freedom in messing with the TPM (and you could use Vanderpool/
Pacifica to virtualize access to the TPM).
> > > Mention OLPC. (But what are the important points?)
> > BIOS can already use wireless
>
> What's it used for?

Booting over wireless if the local flash "hard drive" has been
corrupted. Sort of a recovery mode when no wired network
connection is available.
> > Automatic authenticated BIOS updates
>
> Are the details ironed out yet? Is userspace still involved?

A paper was due a few weeks ago, but nothing has surfaced yet.

Regards,
Carl-Daniel

[Stefan Reinauer]

* Carl-Daniel Hailfinger  [061207 13:19]:
> > Have BIOS check payload you mean? Or have payload check rootfs? I
> > guess they blend into one.
>
> Both. But the BIOS checking the payload is IMO key to a secure boot
> (if you don't trust the payload, you can't trust any assessment of
> rootfs security by the payload).

But: If you can't "trust" the payload, how can you trust the other 64k
of LinuxBIOS in the flash?
> > > Automatic authenticated BIOS updates
> >
> > Are the details ironed out yet? Is userspace still involved?
>
> A paper was due a few weeks ago, but nothing has surfaced yet.

Who is doing that?

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> Carl-Daniel Hailfinger  [061207 13:19]:
> > > Have BIOS check payload you mean? Or have payload check rootfs? I
> > > guess they blend into one.
> >
> > Both. But the BIOS checking the payload is IMO key to a secure boot
> > (if you don't trust the payload, you can't trust any assessment of
> > rootfs security by the payload).
>
> But: If you can't "trust" the payload, how can you trust the other 64k
> of LinuxBIOS in the flash?

You're right. I was unclear with my terminology.
> > > > Automatic authenticated BIOS updates
> > >
> > > Are the details ironed out yet? Is userspace still involved?
> >
> > A paper was due a few weeks ago, but nothing has surfaced yet.
>
> Who is doing that?

Ivan Krstic and others. I'll keep you updated.

Regards,
Carl-Daniel

[Richard Smith]

Peter Stuge wrote:
> Mention OLPC. (But what are the important points?)

Flexibility.   OLPC would have had a _much_ more difficult time getting
things done if it was not using LinuxBIOS.  We have had to do some
pretty custom work under the hood.

Size is another big issue.  It interesting to note that code for the
(8051 microcontroller) EC is *larger* than the LinuxBIOS code and thats
even with romcc generating the LB code.

Of course thats without a payload but an interesting data point.
> Show a demo.

I think for a demo you want to show LaB (Linux as Bootloader, where
linux is in the ROM) and boot linux directly to a shell prompt, as fast
as you can make it.  Thats a short, powerful demo.

[Richard Smith]

Carl-Daniel Hailfinger wrote:
> BIOS bugs can be fixed even if upstream is not ready/cooperating
> (not that I would want to suggest that upstream was uncooperative)

You mean upstream from OLPC here right?  Without a developer key a user
will not be able to reflash the BIOS.

[Stefan Reinauer]

* Richard Smith  [061207 14:28]:
> I think for a demo you want to show LaB (Linux as Bootloader, where
> linux is in the ROM) and boot linux directly to a shell prompt, as fast
> as you can make it.  Thats a short, powerful demo.

Whats the way to go here? Use the stuff with the nice OLPC graphics?
Is that generically usable?

buildrom needs tuning in a lot of places to be non-OLPC it seemed last
time I looked at it.

Is there some way to get it use vesafb (without bios callbacks, see
x86_64 version) rather than a native chipset (ie.  have graphics mode
enabled before starting linux)

Recompiling your bios if you change the graphics card is a little clumsy

Stefan

[Richard Smith]

Stefan Reinauer wrote:
> Richard Smith  [061207 14:28]:
> > I think for a demo you want to show LaB (Linux as Bootloader, where
> > linux is in the ROM) and boot linux directly to a shell prompt, as fast
> > as you can make it.  Thats a short, powerful demo.
>
> Whats the way to go here? Use the stuff with the nice OLPC graphics?
> Is that generically usable?

I /dev/fb0 is the only graphics dependency.  So if you can get a
framebuffer working then perhaps.  I'm not sure if Jordan did some gxfb
custom stuff in there.  It was optimized for size on the OLPC platform.
 Should not be that hard though to make it generic.

For the demo I was more thinking of just the kernel boot messages.  To a
geek like me I'm more impressed with that rather than flashy graphics.
> buildrom needs tuning in a lot of places to be non-OLPC it seemed last
> time I looked at it.

It would need some tuning if you wanted to use buildrom.  I was thinking
 he would just hand roll something.

If someone wanted to try buildrom I can fix up things pretty quick.
Just tell me what LB target to use.
> Is there some way to get it use vesafb (without bios callbacks, see
> x86_64 version) rather than a native chipset (ie.  have graphics mode
> enabled before starting linux)
> Recompiling your bios if you change the graphics card is a little clumsy

If you have run the video bios and you assume that the graphics mode has
been set ahead of time then yes I think we should be able to include
some vesafb code into linuxbios.  The code for a single bit depth,
640x480, no mode changes, slow text, should be pretty small and fairly
easy to maintain since it will not change much.

[Uwe Hermann]

Hi,

On Thu, Dec 07, 2006 at 07:33:16AM -0600, Richard Smith wrote:
> > BIOS bugs can be fixed even if upstream is not ready/cooperating
> > (not that I would want to suggest that upstream was uncooperative)
>
> You mean upstream from OLPC here right?  Without a developer key a user
> will not be able to reflash the BIOS.

Interesting. How does that work and on which level (hardware?
software?). Is there some documentation about this?

Uwe.

[Uwe Hermann]

Hi,

On Wed, Dec 06, 2006 at 09:58:44PM +0100, Peter Stuge wrote:
> On Wed, Dec 06, 2006 at 09:17:24PM +0300, Al Boldi wrote:
> > > Describe what LinuxBIOS is and does,
> >
> > and does not (i.e: not backward-compatible with 16bit bios calls)
>
> Good point, thanks!

Also mention ADLO and that you _could_ probably boot Windows with it etc.
> Also:
> Talk about all the improvements in v3.

Yes, definately! Mention/show kconfig mockup.

Uwe.

[Uwe Hermann]

Hi,

On Thu, Dec 07, 2006 at 02:16:47AM +0100, Carl-Daniel Hailfinger wrote:
> Peter Stuge wrote:
> > Describe what LinuxBIOS is and does, benefits and use cases off the
> >
> > excellent wiki welcome page.
>
> Since C3 is going to be frequented by security-conscious people and
> general interest in tampering with hardware will be high, try this:
> SSH into BIOS for the paranoid
> Authenticated booting
> Using any TPM against the intention of the vendor

Yep, that's great. However, make sure that you mention these are
_possible_ future scenarios, I don't think this has been done yet.
Am I wrong?

Uwe.

[Uwe Hermann]

Hi,

On Thu, Dec 07, 2006 at 11:18:24AM +0100, Peter Stuge wrote:
> > Using any TPM against the intention of the vendor
>
> By using a payload that does tricks before the TPM starts up?

I don't know _too_ much about this topic yet, so I might be wrong, but I
think the TPM chip doesn't actually _do_ anything by itself. It
can be enabled/disabled and configured/used by the BIOS though, and as _we_
control the BIOS in this case we could do all kinds of funny stuff ;)

As soon as I get that darn 440BX RAM init working I'll play a bit with
this stuff, I think.

There's the TPM emulator, http://tpm-emulator.berlios.de/, which will be
useful even if you don't have a physical TPM chip.

Uwe.

[Richard Smith]

Forgot to copy the list:

Uwe Hermann wrote:
> Interesting. How does that work and on which level. (hardware?
> software?).

Both.  There is a latch that controls the write line to the SPI flash
chip.  After looking in a special place for updates it will clear that
latch and it can only be set again by a hard reset.

Each BIOS update is signed with either the master OLPC key or a
developer key unique to that person that will be issued to people by
request.

The BIOS will refuse to update unless the key is verified.

Or you have to remove the SPI chip or reprogram it out of band.
> Is there some documentation about this?

There was a long thread many months ago on the olpc devel list and
lwn.net did an article but thats about it.  Its still in the works.
Most of the crypto code has landed in the repository and should start
seeing some testing around BTest 3. But I'm not sure of the exact
timeframe yet.