Out of curiosity: Can anyone point me where to find how a recent x86-cpu actually boots? Where's the code that gets executed in the first few CPU cycles? The bulk of the firmware, that's clear, nowadays will be fetched from a serially connected flash, which this initial code will copy to the (then initialized) DRAM, also probably in several stages. But where do the first few instructions hide? Mask-rom in the CPU, or…
The first "code" would probably be microcode in the CPU itself, but if you mean x86 instructions, recent CPUs boot in the same way as the orginal 8086: the first instruction after a reset is fetched from FFFF:FFF0, or 16 bytes less than the end of memory, in realmode. The BIOS ROM is mapped into this area.
http://puri.sm "The first high-end laptop that respects your freedom and privacy. The Purism Librem 15 is the first laptop in the world that ships without mystery software in the kernel, operating system, or any software applications."
The Gluglug (http://shop.gluglug.org.uk/product/ibm-lenovo-thinkpad-x60-c... ), basically a Thinkpad X60 with Coreboot, beat them to "first laptop in the world" (PC-compatible, at least), but maybe not "first high-end laptop". I think there's optional non-free microcode updates that might be useful, but it can definitely run 100% blob-free.
Macs used to require a physical step in addition to the software setup to modify the boot ROM. I think it was something along the lines of load firmware update which initiates a reboot, after reboot press and hold the power button until there was a loud beep from the computer, then the firmware update could proceed. Not convenient, but more secure.
That's resetting the PRAM and was required on old macs for some of the fimrware changes to actually take place (since the firmware was cached).
No, resetting PRAM is triggered by holding down command-option-P-R. This was a special step that was required specifically for firmware updates.
Out of curiosity: Can anyone point me where to find how a recent x86-cpu actually boots? Where's the code that gets executed in the first few CPU cycles? The bulk of the firmware, that's clear, nowadays will be fetched from a serially connected flash, which this initial code will copy to the (then initialized) DRAM, also probably in several stages. But where do the first few instructions hide? Mask-rom in the CPU, or…
The first "code" would probably be microcode in the CPU itself, but if you mean x86 instructions, recent CPUs boot in the same way as the orginal 8086: the first instruction after a reset is fetched from FFFF:FFF0, or 16 bytes less than the end of memory, in realmode. The BIOS ROM is mapped into this area. There are some good articles here: https://sites.google.com/site/pinczakko/
> the first instruction after a reset is fetched from FFFF:FFF0
I trust you that this logically will certainly be true, but: what memory will that access to ffff:fff0 be mapped to if the "bios" in my PC is stored in a SPI flash that certainly can't be connected directly to anything resembling a "address/data-bus" in a modern PC...
I believe that the two year old Option ROM vulnerability to which this post refers was this one described by Loukas(snare) at Black Hat and Ruxcon 2012: https://www.youtube.com/watch?v=XcFvgAsfdqg
Although I may be wrong, it's certainly a related vulnerability and an interesting presentation to watch. Skip to ~54mins if you just want to see the demo.
The first "code" would probably be microcode in the CPU itself, but if you mean x86 instructions, recent CPUs boot in the same way as the orginal 8086: the first instruction after a reset is fetched from FFFF:FFF0, or 16 bytes less than the end of memory, in realmode. The BIOS ROM is mapped into this area. There are some good articles here: https://sites.google.com/site/pinczakko/
> the first instruction after a reset is fetched from FFFF:FFF0 I trust you that this logically will certainly be true, but: what memory will that access to ffff:fff0 be mapped to if the "bios" in my PC is stored in a SPI flash that certainly can't be connected directly to anything resembling a "address/data-bus" in a modern PC...
If I recall corretly, the access is mapped to the SPI flash chip which is memory-mapped into the CPU address space by the chipset. Access to this address range is of course relatively slow, but that's always been true of BIOS flash.
The first "code" would probably be microcode in the CPU itself, but if you mean x86 instructions, recent CPUs boot in the same way as the orginal 8086: the first instruction after a reset is fetched from FFFF:FFF0, or 16 bytes less than the end of memory, in realmode. The BIOS ROM is mapped into this area. There are some good articles here: https://sites.google.com/site/pinczakko/
> the first instruction after a reset is fetched from FFFF:FFF0 I trust you that this logically will certainly be true, but: what memory will that access to ffff:fff0 be mapped to if the "bios" in my PC is stored in a SPI flash that certainly can't be connected directly to anything resembling a "address/data-bus" in a modern PC...
There is circuitry that translates the requests from the CPU into read commands to the serial flash. Depending on the system, this can be in the LPC-connected SuperIO, the southbridge, or on laptops more likely part of the EC (embedded controller) which is also connected via LPC. This is also why executing from the BIOS is slow - SPI flash bandwidth is in the dozens of MB/s range, and if it's going over LPC the max bandwidth on that is If you're really interested in this stuff the articles in the above link are a good read, as well as datasheets for the various chipsets involved. I'd recommend even looking at the original IBM PC/AT Technical Reference, with BIOS listings and full schematics.
http://puri.sm "The first high-end laptop that respects your freedom and privacy. The Purism Librem 15 is the first laptop in the world that ships without mystery software in the kernel, operating system, or any software applications."
Thanks for the link. Who are the guys behind this?