Introduction to Coreboot, an open source BIOS
lennartb.home.xs4all.nl
lennartb.home.xs4all.nl
Part 3:
"Running C code is a bit more difficult. The problem is that the code generated by any standard C compiler for the x86 CPU will heavily depend on RAM. System RAM is not enabled yet and the code to enable it is so complex that you really want to do it in C. Two solutions have been devised and both of these are in use (one or the other depending on the hardware).
Use a special C compiler (romcc) that does not make use of RAM, but keeps all data in registers. As the register set of the x86 is quite small (only 8 general purpose 32-bit registers), this severely limits the things that your C program can do. As the CALL and RET instructions cannot be used (they always use the stack in RAM), all C functions have to be inlined. Use the CPU cache as a data RAM. This requires some special tricks to pretend that all cache lines contain valid data and to prevent them from being evicted. Which tricks are exactly required, depends on the exact model of CPU, but it can be done. The Cache As RAM trick (CAR) yields at least 16kB of usable RAM, sufficient as stack space for a simple C program. All recent hardware ports use this trick."
Mind. Blown.
Is this something that happens to the children of the IBM PC or is this "feature" present in other machines?
I understand someone may want to tune memory controller parameters, but can't it initialize itself with sensible defaults?
You have to query something (often a eeprom) to determine what sort of timings you need, and then program the memory controller appropriately.
Another interesting thing, no matter how many cores the CPU have, it always starts in single-core mode and you have to switch the other cores on.
Furthermore, most embedded platforms simply hardcode the timing values for the variety of RAM that they put down on the board. Since you know that the RAM, CPU, and board won't change, you can calibrate once and be done with it.
For Novena, we support swapping DDR3 modules, so we need to recalibrate on every boot. We're not so restricted, since we have a good 128k (or 256k) of on-chip cache-as-RAM, so we just do it all in C. Of course it starts out with reading the RAM configuration out of the SPD chip on the module, but timing calibration must be completed regardless. If you're curious, the code we use to do this is available at https://github.com/xobs/u-boot-novena-spl/blob/u-boot-spl-no...
coreboot time (as per cbtime) : 1.5s, followed by kernel and system boot in (as per systemd-analyze) : Startup finished in 2.244s (kernel) + 611ms (userspace) = 2.856s
I'm using grub2 as a payload, and that's what I call a fast boot for a debian Wheezy (details on http://www.coreboot.org/pipermail/coreboot/2014-July/078215....)
But you can use other payloads too - even chainloading them from grub!
"stealing the VGA bios" in column 4 is not mandatory if your hardware supports native video init, and today I just succeeded in replicating the video support using SeaBIOS (cf http://www.coreboot.org/SeaBIOS and http://www.coreboot.org/pipermail/coreboot/2014-February/077...), which means that I can now load a standard grub and maybe other operating systems should I want to use them on the X60, without any blackbox blob - who knows what may be hidden in these blobs.
Why is that interesting? Because in the default bios (cracked open with bios-extract, Phoenix BIOS "Phoenix FirstBIOS(tm) Notebook Pro Version 2.0 for ThinkPad") there is Computrace backdoor as option rom 2E (cf http://securelist.com/analysis/publications/58278/absolute-c...).
If I ever need to do things on a windows machine, I don't want bios rootkits - and coreboot makes that possible, thank you :-)
If you like playing with operating systems, boot, etc. coreboot is very cool.
A very dangerous piece of propietary software preinstalled in all corporate laptops that you cannot deactivate, uninstall or even patch. It may not be a rootkit, but surely can be used as one.
Either way it's not so hard to remove that option ROM and reflash the BIOS. ;)
Also, which tool would you use to remove this option rom? CBMROM does not works on phoenix firstbios, and the phoenix editor tools don't work on the 2 Mb image.
I'd be delighted to know, just because I have that it's still there on my "reference" motherboard (used to test whether issues are due to coreboot or not)
phdecomp + phnxdeco worked to unpack the BIOS into its modules; it shouldn't be difficult to reassemble it without the Computrace module and fix up the checksum, then reflash. But on the other hand, since the C&C server can be modified, maybe it might be more fun to activate it after pointing it to a server I own, and then I get a free backdoor that I can use...
I have no idea on how to reassemble the pieces into a working bios. It's not just a checksum, that's for people doing SLIC ie replacing or adding stuff at the bottom. A missing table in the middle might cause problems. Isn't there an index too?
Anyway, the alternative hack you suggest would be quite a cool one :-) I didn't know it was possible to change the address of the c&c in the option rom (IIRC, it's like packed in an EFI header, then again - I just don't know which tools to use), but if it's, I'd be quite interested - even more if the computrace protocol has ben reverse engineered ;-)
Feel free to contact me by email!
Also, in Blackhat 2014 Anibal (one of the original core researchers) will present a complete reversing of the computrace protocol.
The X60 is a good option, too.
Looks like the hardware support situation haven't improve a single bit since the last time I looked into coreboot. That's a pity.
How well does the computer work, when it is supported? Are there stability issues? Is performance the same? Do all of the same devices work, as with proprietary BIOS?
When it is supported, there are different outcomes. The individual board pages on the wiki can offer more details. The X60 is especially well supported because of a combination of factors:
1. Lenovo was actually pretty helpful
2. Lots of coreboot hackers have worked on the machine for years
3. Lots of other linux hackers have also worked on various parts (which improves the support for all the devices)
So without doing any research, my understanding is that the X200s and to a lesser degree the X230 cannot achieve that level of support, mostly because it would take the coincidence of all that work coming together. But it's not all bad: the Chromebooks are getting that work done by a group of paid engineers, and there is a recent addition to the supported laptops (not fully open, but close; not amazing hardware, but decent) - the HP m6-1035dx.
I got an HP m6-1035dx on ebay, and my experience is that everything works fine. I suggest throwing away the mini PCIe wireless card it comes with and putting in a better one, but I haven't brought it up on the coreboot mailing lists because it's not really coreboot's fault. HP just built a cheap laptop and so it has a junk wifi card.
Hopefully that helps? Cheers!
Also, almost all BIOSes go into flat real mode ("unreal mode") not far from the reset entry point, as otherwise they would be unable to access most of the memory and devices in the system.
If you're interested in BIOS stuff one of the things I'd recommend is to get a copy of the PC/AT technical reference - the full BIOS listings are in there, and make for great studying of historical significance since much of the hardware has remained essentially software-compatible since then, only physically changed form. For example, the latest 8-series chipsets for i5/i7 still contain a pair of 8237s, 8259s, and an 8254 in the same configuration as the original AT.
Here is someone who could boot the very first version of DOS on a Ivy Bridge system: http://www.msfn.org/board/topic/153995-will-ms-dos-3x-run-on...
I would not be surprised if there is someone at Intel or Microsoft whose job it is to do just that for every release.
For BIOS services, there's SeaBIOS (www.seabios.org) which we can run as a payload. DOS works fine with it.
" In the 1980s the functionality of a microcomputer was determined at least as much by its firmware in ROM as by its hardware. The Apple MacIntosh might have had a similar hardware architecture to the Atari ST, but each had its own different operating system in ROM.
Of course there were those brave people who would replace the ROM chips inside their computers by ROMs they had programmed themselves, so they could regain complete control over their machines, which was lost when the front panel had disappeared. Coreboot is just such an endeavor. "
it's nice that everyone can compile an android rom, but with closed drivers and proprietary boot managers we are in that precarious state...
Combining coreboot and Tianocore can build an open source x86 UEFI. But unless you need the network boot feature, UEFI is a waste of time and space.
It's good enough for KVM (that Linux virtualization technology), which boots Windows all the time.
But seabios is much, much easier to integrate because it has fewer moving parts
There is also talk, and perhaps actual implementation, of TianoCore running on top of coreboot.
SeaBIOS is also used by VirtualBox, and probably Xen as well.
And when it comes to open firmware standards, why didn't Intel go with IEEE1275 but invent its own? firmware standards really exist aplenty, defusing any claim that any single one of them "should" be implemented because it's a standard.
New Win8.x machines are required to boot using UEFI, and OF on x86 was never popular anyway. To show some of the harms this situation have caused BTW, LKML has a lot of posts about various UEFI firmware bugs, and remember that Chrome OS is based on the Linux kernel.
No moving parts means no worries - that's a lesson the UEFI architects never understood.
So they built that living hell of runtime composable components for something that generally tries to get out of the way in as few milliseconds as possible. Some of these components survive long into the operating system's domain, messing things up there. The architecture doesn't allow for build time controls (eg. why did boot services used by runtime services, a common bug a couple of years ago, not trip up a linker? because they incapacitated the linker through this design).
And best of all, thanks to Intel relentlessly pushing that crap into the market, we'll get to "enjoy" it for the next three decades or so.
Apart from being able to check the "Windows" checkbox on marketing material, I actively avoid UEFI because of this horrid imitation of software design.
UEFI is that bad.