[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: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Laurent Lesage
> Sent: Monday, October 21, 2013 6:15 PM
> To: coreboot at coreboot.org
> 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
>
>
> --
> coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen, Deutschland
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
> Registergericht: Muenchen HRB 47456
> Ust.-IdNr./VAT Registration No.: DE129385895
> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
>