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
On Wed, Dec 06, 2006 at 09:17:24PM +0300, Al Boldi wrote:
Good point, thanks!
Also:
* Talk about all the improvements in v3.
//Peter
Hi,
On Wed, Dec 06, 2006 at 09:58:44PM +0100, Peter Stuge wrote:
Also mention ADLO and that you _could_ probably boot Windows with it etc.
Yes, definately! Mention/show kconfig mockup.
Uwe.
Peter Stuge wrote:
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
* 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
Great stuff! Thanks for the input!
On Thu, Dec 07, 2006 at 02:16:47AM +0100, Carl-Daniel Hailfinger wrote:
Have BIOS check payload you mean? Or have payload check rootfs? I guess they blend into one.
By using a payload that does tricks before the TPM starts up?
What's it used for?
Are the details ironed out yet? Is userspace still involved?
Oh yes.
//Peter
Peter Stuge wrote:
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).
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).
Booting over wireless if the local flash "hard drive" has been corrupted. Sort of a recovery mode when no wired network connection is available.
A paper was due a few weeks ago, but nothing has surfaced yet.
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [061207 13:19]:
But: If you can't "trust" the payload, how can you trust the other 64k of LinuxBIOS in the flash?
Who is doing that?
Stefan Reinauer wrote:
You're right. I was unclear with my terminology.
Ivan Krstic and others. I'll keep you updated.
Regards, Carl-Daniel
Hi,
On Thu, Dec 07, 2006 at 11:18:24AM +0100, Peter Stuge wrote:
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.
Carl-Daniel Hailfinger wrote:
You mean upstream from OLPC here right? Without a developer key a user will not be able to reflash the BIOS.
Hi,
On Thu, Dec 07, 2006 at 07:33:16AM -0600, Richard Smith wrote:
Interesting. How does that work and on which level (hardware? software?). Is there some documentation about this?
Uwe.
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.
Hi,
On Thu, Dec 07, 2006 at 02:16:47AM +0100, Carl-Daniel Hailfinger wrote:
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.
Peter Stuge wrote:
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.
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 smithbone@gmail.com [061207 14:28]:
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
Stefan Reinauer wrote:
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.
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.