[coreboot] software hardening research project - request for advices to start

[Patrick Georgi]

Am 21.11.2013 12:50, schrieb Laurent Lesage:
> So I understood that, indeed, a very quick boot is possible. That's
> fine. So, the POST may be done when "cold start" is done. It's only when
> I want to make a reboot that I need it to be as fast as possible. When
> you say " shallow warm restart
>
> it speaks well to me, though I've still no idea of how to do it. ... if
> I google those words "shallow warm restart + coreboot" .... I just find
> this email thread in first position!!! Can you give more tips on haow to
> go in this direction?
You can reduce the time for initializing RAM by assuming that the 
configuration didn't change (typically a given on embedded hardware). 
This is implemented in coreboot for current AMD and Intel chipsets.

You can also postpone some hardware initialization to a later stage, but 
that's a bit more involved.

And then there's the option that you essentially keep the system in 
suspend-to-ram mode, so "power up" equates "wake up" (which is _really_ 
fast, and you can jump into a prepared OS state, too). I suspect that 
this is what Zoran is alluding to.
It depends on your application if that is an option or not...

All of these options depend on some trusted hardware configuration (part 
of which is in flash), so that might or might not be acceptable for your 
use case.

> I also saw that it was possible to flash coreboot + payload on the chip
If your software is simple (and in particular: small) enough, it can 
serve as a payload. We have libpayload (part of the coreboot source 
tree) to provide common libc functions and a bunch of drivers.

In theory you could run everything from ROM, but coreboot isn't prepared 
for that (we unpack the later stage to RAM), so you'd need to adapt that 
for your use case.
You'll also have to be careful not to kill performance. Caching the ROM 
might help - we do that, but probably not good enough for such a scenario

> Is UEFI and EDK necessary? I read that UEFI support was not yet
> complete.
The UEFI payload for coreboot isn't yet complete.

> EDK is the tool provided by SAGE, I think : is it GPL too? At
> this time we do not have budget to hire anyone... MAybe in the future if
> we can set this experiment which has never been done.
EDK is also the "EFI development kit" - it's unclear what Zoran meant, 
given that he also brought UEFI into the debate.

> About the test board :
> At this point, my idea is to use coreboot + Qemu to put my hands on
> coreboot and try to do what I described.
That's a great idea since it teaches you about the coreboot build 
process and its architecture. However since Qemu takes a couple of 
shortcuts, it's limited in what hardware behaviour you can model.

> I suppose (am I right?) that if
> it works that way, it would be possible to use what I learned to put it
> quite easily on a "real" board?
AMD's SimNow provides a more complete emulation, and it models "real" 
hardware, so the same image (sans workarounds for emulation bugs) can be 
used on the corresponding hardware.
However it's non-free and its learning curve is a bit steep.

> Is Intel or AMD more suited to those needs? What do you think?
Intel chipsets come with the management engine, which sometimes 
interferes in the boot process. AMD has less of that stuff, so I guess 
you have more control over the platform characteristics.


Patrick