6 ms·
Does anyone know how to circumvent UEFI? When the CPU starts, it will start reading instructions from a hard-coded address on the memory bus / EPROM somewhere,
by heinrichhartman 7y ago
Does anyone know how to circumvent UEFI?
When the CPU starts, it will start reading instructions from a hard-coded address on the memory bus / EPROM somewhere, right? How can I directly control these bytes?
I don't want some proprietary firmware sit between me and the CPU.
If it's not possible on hardware because "secure boot", or whatever, this should at least be possible in emulators like QEMU.
Does anyone know how to do that? ... or clear up my misconceptions? :)
- deleted 7y ago[deleted]
- kryptiskt 7y agoBelow UEFI is the BIOS, or the firmware formerly known as the BIOS. There is a project to make an open source firmware for PCs: https://www.coreboot.org https://www.coreboot.org. It works on a selection of newish motherboards. You can't really start completely from scratch in an understandable way on Intel platforms, and it's iffy on ARM. Because setting up the DRAM requires some insane magic, where it doesn't really help if you can see the source.
- deleted 7y ago[deleted]
- wolfgke 7y ago> Below UEFI is the BIOS, or the firmware formerly known as the BIOS. Source? As far as I am aware, UEFI is a replacement for BIOS.
- Rusky 7y agoI believe they're using BIOS in a more general sense. You're right that UEFI replaces the old BIOS APIs that bootloaders used, but there's still firmware (e.g. coreboot) below or part of its newer APIs.
- izacus 7y ago> Below UEFI is the BIOS, or the firmware formerly known as the BIOS. There is a project to make an open source firmware for PCs: https://www.coreboot.org https://www.coreboot.org. It works on a selection of newish motherboards. This simply isn't true - while UEFI firmwares do offer BIOS emulation, there's no "BIOS" underneath them on most modern boards.
- XMPPwocky 7y agoThey might mean the "meta-bootloader" which brings up all those UEFI capsules- afaik Intel's boot ROM doesn't, for example, parse PE headers.
- Wowfunhappy 7y agoI really hate to be the downer here, but have you heard of Intel's Management Engine? :(
- Koshkin 7y agoWell that one runs on a separate (albeit embedded) CPU.
- ngneer 7y agoGreat question. Things have gotten ridiculously complex. You might look into https://wiki.osdev.org/UEFI https://wiki.osdev.org/UEFI
- pjc50 7y agoIn QEMU it's dead simple, you have control of everything; I believe that it boots into https://github.com/qemu/qemu/tree/master/pc-bios https://github.com/qemu/qemu/tree/master/pc-bios A physical machine will still, despite everything, start executing at FFFF:0000 in "real mode", and the code run there will be found in a physical EEPROM. Some of these are socketed (although this is less common these days). So you can get in there and fiddle with the pre-boot code. See https://www.drdobbs.com/parallel/booting-an-intel-architecture-system-par/232300699 https://www.drdobbs.com/parallel/booting-an-intel-architectu... There is no way round the Management Engine, a source of distress to some. Oh, and you won't have any DRAM until you've run the DRAM training and turned that on, the early BIOS gets to use the cache as a scratchpad instead. See https://blog.asset-intertech.com/test_data_out/2014/11/memory-training-testing-and-margining.html https://blog.asset-intertech.com/test_data_out/2014/11/memor... If you like bare metal work with decent processing power ARM is probably the place to start.
- saagarjha 7y agoDoesn't every ARM machine have its own initialization sequence?
- XMPPwocky 7y agoYes, but if you can find a chip with public documentation, it's a well-defined initialization sequence. I learned assembly on TI's AM335x "Sitara" series and it was great, mostly because of the BeagleBone- it has onboard JTAG-over-USB, meaning you can single-step your way through your bare-metal code, set breakpoints, etc.
- Gibbon1 7y agoUnsure about the high end ARM machines. But an ARM Cortex boot consists of loading the program counter and stack pointer from ROM and go.
- monocasa 7y agoThey're all cortex cores these days, you mean the Cortex-M series.
- stefan_ 7y agoThat is not really a thing anymore, most processors now have burned-in ROM from the vendor that they boot into first. If you really want to understand and control a processor when it boots from nothing, you should look into a FPGA RISC-V development board.
- mkup 7y agoHardware initialization after power-up is HARD, here a high-level overview: https://depletionmode.com/uefi-boot.html https://depletionmode.com/uefi-boot.html
- duskwuff 7y ago> I don't want some proprietary firmware sit between me and the CPU. No, you do. A significant part of what that firmware does is initializing low-level hardware, like the system's memory controller. Replicating that is probably well beyond your abilities.
- Taniwha 7y agoSeriously, it's not just a matter of poking a few registers - it involves doing a bunch of statistical measurements of memory errors to pick the correct thresholds on the data bus
- duskwuff 7y agoAnd it's rather hardware-specific. Even if you have a solution which works for your CPU / motherboard / RAM, changing any of those components is quite likely to make it stop working. (And lord help you if you want it to work across CPU manufacturers...)
- some_random 7y agoI mean, ideally it would be open-source and verifiable. But damn there's no way you're going to hackernews it in a weekend
- guerby 7y agoThis RISC-V board has about zero closed source code in its boot sequence: https://www.sifive.com/blog/an-open-source-release-of-the-freedom-u540-c000s-bootloader https://www.sifive.com/blog/an-open-source-release-of-the-fr...
- korethr 7y agoGo check out the Coreboot project. They're about as low-level and bare metal as you can get, because Coreboot is not running on the board firmware, it is the board firmware. And as an open source project, they document all the various things they have to do in order to initialize all the hardware on a board and have it ready to be used. You are generally correct in your assumption: that once the CPU comes out of reset, it will reach for a particular memory address to begin execution. Some will directly begin execution from a fixed address. A sibling pjc50 comment mentions, on x86, the CPU will be in 16-bit real-mode and begin fetching instructions from FFFF:0000. Other architectures, work slightly differently. Motorola 68k fetch the first 4 bytes from 0x00000000, loads them into the program counter register, and then jumps there to begin execution. As you saw, the child of a pjc50's comment explains how to pass your code directly to the beginning of the CPU's execution in QEMU. If you want to do this with actual metal, various classic chips of yore (z80, 6502, 68k, etc) and their documentation are relatively easy to get. A nice thing about those older CPUs, is that their memory interfaces are rather simple compared to today. You can wire up a very basic system with the CPU, an EPROM, an SRAM chip, and maybe a couple other chips as glue logic, all on a basic breadboard. And then you really can control those first bytes of executed code, on actual metal.