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: [email protected] [mailto:[email protected]] On
Behalf Of Laurent Lesage
Sent: Monday, October 21, 2013 6:15 PM
To: [email protected]
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: [email protected]
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
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
