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

[Laurent Lesage]

Hello Zoran,

Thanks for your answer. I googled a bit coreboot and read the short SAGE 
guide. My understanding is a bit better, but I've not yet begun to put 
my hands on it. Before that, I ask again some advices.

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?

I also saw that it was possible to flash coreboot + payload on the chip 
: this is a very interesting option, because we also have to protect the 
software against a mad CPU (it will be, as we will cause bitflips in it 
with ions irradiations). If the soft is in the ROM, we may consider it 
is safe. In case of error (that is, if the CPU is in an infinite loop, 
or triggered any exception), the only thing that would have to happen is 
a reset, that is (as far as I can express it) :
-restart the payload only (an so reload it from ROM) = we consider that 
the RAM content is corrupted.
-of course, the cache will have to be reset (also considered as corrupted)
-the system should be in the same state as when it started, except there 
should be no need to make a POST again.
-may be do things I do not yet know about...
All that stuff is the "shallow warm restart" as far as I understand. AM 
I right?
And yes, the software is as simple as possible, that is, no threads, 
only C code on bare metal. No interrupts : the only interrupt authorized 
is to reset the CPU, but this should be triggered with a watchdog and/or 
the PCIex board which will hold and FPGA and some kind of protected 
memory (i. e. protected against the "mad" processor).

Is UEFI and EDK necessary? I read that UEFI support was not 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.

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. 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?
Is Intel or AMD more suited to those needs? What do you think?

Laurent

On 22/10/13 09:48, Stojsavljevic, Zoran wrote:
> Hello Laurent,
>
> I can give you my own tips for doing what you have asked. Few of them...
>
> I don't understand why you need to modify BIOS? Instead, you can keep your SW on the USB mass storage. And go from there. The another approach is to boot to DOS 6.2 on USB and perform tests from there. DOS is a linear OS, does not have MMU engaged, does not have HW multithreading (my best understanding).
>
> If you will use INTEL CPUs, you can go with FSP approach as well, and put Coreboot on the top of it, using your SW as Coreboot payload. One of the viable solutions, but you need also to have Management Engine (ME) SW added there (in single, or dual spi design, ME placed in spi0, BIOS in spi1).
>
> If you would like to boot with less than 1 ms, you need to do shallow warm restart, so you need just to be able to free HW resources (since I think you'll use ONLY one HW thread, one core sans hyperthreading, all others while in BIOS are disabled), flush cashes, do memory garbage collection (if any?) and jump to the beginning of your test SW. Not sure while performing shallow warm restart if you need to do something with System Management Mode (SMM) and it structures. Topic to be investigated.
>
> Please, do notice that BIOS and FSP, both do for you PCIe enumeration. For the boards, I'll advise you for INTEL to use IVB and later (HSW) based. This are the primary CPUs for INTEL to keep supporting 'em for long time (at least for 7 years from date of public release, 2012 for IVB, 2013 for HSW).
>
> Now, specifically to your questions:
> [1] YES, it is possible to modify BIOS to disable POST, and do certain configuration, you need to use Open Source (with incorporated binaries doing SEC and PEI) EDK2 package (UEFI BIOS) which has options for various configurations;
> [2] YES;
> [3 - 4] I don't know. I am using INTEL's CRBs, these are unlocked always. Not sure about commercial boards, and which are the best for such experiments.
>
> Zoran
> _______
> Most of The Time you should be "intel inside" to be capable to think "out of the box".
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Laurent Lesage
> Sent: Monday, October 21, 2013 6:15 PM
> To: [e-mail]
> Subject: [coreboot] software hardening research project - request for advices to start
>
> Hello all,
>
> After having searched around me for some answers about BIOS and PC board "hacking", I want to ask directly to the "core" developers.
>
> In short, I would like to run a test software without OS (say, like
> "memtest") on a standard mainboard. This software will have to access a PCIe board, and may be some components of the mainboard. So we expect the software will not exceed a few hundred kilobytes. During this experiment, we want that a reset of the CPU does not lead to a reboot, but just restart our software immediately (only a cold start would redo all the usual "POST"), skipping all the usual hardware setups.
> "immediately" means in one ms or so (the less, the best). More details about what I'm working on at the end of this post. To achieve this on standard mainboards, being able to modify the BIOS seems the only way.
>
> My questions /request for comments and advices :
> 1.Is it feasible to modifiy the BIOS for such a reset (without POST and very quickly).
> 2.Is it possible to put our software on the BIOS chip, so that we do not need to access hard disk, and so that the code is protected (Read only) during the runs.
> 3. is it possible to flash the BIOS without locking the board, i.e., is it always possible to recover a working bios if flashing process failed, or experimental BIOS is not working as expected. In that sense, are there boards to avoid?
> 4.knowing we will have to access a PCIex8/16 extension board, and knowing the points 1, 2 and 3, which board would you advice to use? For example, I saw this one ( http://www.coreboot.org/ASUS_F2A85-M#Hardware_info ) for which PCIe support seems OK. Of course, the board must be easy to buy, so older ones are not a good choice if they are sold out.
>
> I also saw that some boards offers bigger space to flash BIOS. Again, this would be a good criterion for our needs, if it is possible to flash our software in it using the remaining space.
> What I wish is to start with a mainboard that has more than 90% of probability to meet our needs.
>
> Some more details about the project.
> I'm research engineer in UCLouvain (Belgium). Our topic is "software hardening for mission critical embedded software". Quickly said, we want to test our approach with COTS hardware (usually, testing is done on FPGA systems, or specific hardened  hardware systems). So, we want to use a PC board to run a very specific software on it (that could be the "payload" coreboot can start). We intend to make this in two stages :
> -first tests on a "naked" machine i.e. without OS. Our software is the payload. That is the subject of this post.
> -later, run a software hardened version of Minix (I saw minix is not yet usable as such but if we come to this end, we will have some knowledge to go this way).
> The CPU of our "naked machine" will at the end be irradiated to inject error in it, and see if it detects errors and stays working despite transient faults.
>
> Regards
>
> Laurent
>
> board with special memory and FPGA on it

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

software hardening research project - request for advices to start

[Gerd Hoffmann]

Hi,
> > 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.

In particular:
  * Easy CPU bringup.  No microcode loading.  CPUs are there and
    just work ;)
  * Easy northbridge setup.  For example there is need to read spd
    from dimms for ram detection (to be exact it is impossible,
    qemu doesn't emulate that).  There is a special interface instead
    which the firmware can use to detect the virtual hardware.
  * No pesky EC to manage.

Southbridge setup is largely identical to physical hardware, qemu
mainboard emulation simply compiles the regular coreboot southbridge
drivers for the emulated hardware (which is not the case for northbridge
and cpu).

cheers,
  Gerd