Tear out that BIOS

[0b00000000]

Imagine the scenario that we are developing for an environment with no BIOS (BIOS broken, BIOS being developed (unstable), BIOS purposefully removed for security (paranoid) reasons).

I wonder if it would be possible to come up with some kind of hardware and/or software solution that can load code into memory and have the processor execute it.

0x00

[mallard]

You mean like (U)EFI, Open Firmware or Coreboot/Libreboot?

[0b00000000]

You mean like (U)EFI, Open Firmware or Coreboot/Libreboot?

No, I mean an older system with no (U)EFI with a broken BIOS or BIOS removed or BIOS under development and therefore undefined behaviour. How does a BIOS load the first sector anyway? I guess that is the real question.

0x00

[alexfru]

Imagine the scenario that we are developing for an environment with no BIOS (BIOS broken, BIOS being developed (unstable), BIOS purposefully removed for security (paranoid) reasons).

Imagined. Still terrified of the possibility that the CPU is spying on me or going to die when it receives a command to.

I wonder if it would be possible to come up with some kind of hardware and/or software solution that can load code into memory and have the processor execute it.

Sure. Upon reset the CPU starts fetching instructions from memory at a pre-defined location (either fixed or programmable (by tying certain CPU pins to high or low)). You need more? Extend from here.

[0b00000000]

Imagine the scenario that we are developing for an environment with no BIOS (BIOS broken, BIOS being developed (unstable), BIOS purposefully removed for security (paranoid) reasons).

Imagined. Still terrified of the possibility that the CPU is spying on me or going to die when it receives a command to.

I guess there's a reason the company is called 'intel'.

I wonder if it would be possible to come up with some kind of hardware and/or software solution that can load code into memory and have the processor execute it.

Sure. Upon reset the CPU starts fetching instructions from memory at a pre-defined location (either fixed or programmable (by tying certain CPU pins to high or low)). You need more? Extend from here.

What is that pre-defined location. How can we load code to that location?

0x00

[iansjack]

Of course you have to get the code into that memory in the first place before you can execute it. So it needs to be in some sort of read-only memory. There only need to be a few basic routines in that read-only memory to do things like read sectors from a storage device. I'm going to call this read only memory my Better Independent Operating Stuff.

The alternative would be to have a number of toggle switches so that you could load the instructions into RAM one-by-one. But that's probably a bit futuristic right now.

[Kazinsal]

You are certainly asking a lot of questions that can be answered with basic google skills.

[neon]

Hello,

What is that pre-defined location. How can we load code to that location?

The CPU starts fetching instructions from ffff:0, 16 bytes below 1MB. The physical address space reserves f0000-fffff for the BIOS ROM Core Image, so typically there would be a jmp at ffff:0 to the Core Image entry point to perform basic initialization. Now for the problems -

1. This is ROM mapped into the physical address space.
2. Would require flashing the EEPROM which you cannot expect users to do.
3. Chipset initialization is very dependent on the model, vendor, and type of motherboard.
4. You cannot use memory of any type until you initialize north bridge. See (3).

So is it possible? Of course. Is it feasible? Not a chance. Is it useful? Not a chance. Modern BIOS's are written in assembly language and C with custom compiler ports due to their complexity. They are not simple projects. All BIOS's are buggy. however they are all good enough to boot your software.

With that said though, I don't see why you can't write over the EEPROM through chipset specific registers. This would be the equivalent of flashing the BIOS.

How does a BIOS load the first sector anyway?

The same way operating systems do it: sending commands to the FDC, ATA, EHCI, etc. The firmware must support loading of any sector the device permits and abstract device objects in a systematic way. (E.g. Booting USB-FD or USB-HDD emulated devices through standard int 13h services.)

[intx13]

The firmware is essentially a complete OS whose job is to initialize the memory controller, the PCI controller(s), the USB controllers, the VGA controllers, and so on, load a bootloader, and provide an API (either legacy - via interrupts - or UEFI) for that bootloader to call as needed. This OS is stored on a Flash ROM which is hard-wired to the memory controller. The memory controller starts up with a basic built-in configuration so that when the CPU issues an address space read/write to an address in the range 0x000F0000-0x000FFFFF, the memory controller sends it to the Flash ROM. The CPU starts up by setting CS to 0xFFFF and IP to 0x0000, causing it to fetch instructions from physical address 0x000FFFF0. This is in the range above, so those instructions are fetched from the Flash ROM.

The firmware code is very constrained at first, since the memory controller itself isn't fully configured. That means it can't even store variables in RAM, since the DRAM chips aren't enumerated yet. So it uses special tricks (either cache-as-ram or compiling to only use registers) until it configures the memory controller. Once the memory controller is up, the firmware can start using RAM and then things get easier.

There's nothing stopping you from writing your own firmware, but it is a very complicated task. Open-source firmwares have been written for Bochs and QEMU.

[Brendan]

Hi,

For modern computers; when you first turn a computer on; the CPU starts executing at 0xFFFFFFF0 (the "impossible" real mode address 0xFFFF0:0xFFF0); and various parts of the chipset (e.g. memory controllers) haven't been configured yet so you can't even use RAM. Firmware starts by auto-detecting the number, size and type of RAM chips installed; and configuring memory controllers, quick-path or hyper-transport links between CPUs/chips, MTRRs, etc.

Once RAM can work (for BIOS systems) it would "copy" (possibly including decompression) a piece of itself into RAM at 0x000F0000, and then set this area of RAM (in the memory controller) as "read only". Then it'd do PCI bus enumeration/configuration; including copying "device ROMs" into RAM (in the area starting at 0x000C0000), calling the "ROM in RAM" code's initialisation/entry point, and setting those area of RAM (in the memory controller) as "read only" too.

Somewhere in the middle of this it'd also build things like ACPI tables, by stitching together some "hard-coded" pieces and some information from detection (e.g. number of "non-faulty" CPUs that it managed to find/start); and install SMM handlers somewhere and set that up; and do a bunch of other things.

Eventually (after most of its work has been done); it'd (optionally) disable A20, and switch to real mode and pass control to the small piece of itself that it copied to 0x000F0000. It's this small piece that provides BIOS functions and handles booting from devices.

Now...

If the firmware is broken, being developed, or was purposefully removed "for security" (idiocy); you end up with an expensive but useless brick where (almost) none of the hardware (not even RAM) can function. Ironically, even in this completely useless/broken state, the dedicated micro-controller/CPU used for Intel's Active Management will probably still be running, and will still be able to do anything it likes in the background.


Cheers,

Brendan

[ggodw000]

i have couple of years exp. developing bios but last few years I was into qa and some of the technicals are fading away.
Very 1st time, pc is powered on cpu starts instruction from fffffff0 and you have to make a couple of jumps into real-mode boundary (<1mb) as CPUs are in real mode)
after that roughly system components are init-d in the following order:
cpu
memory
video + option ROMs
boot order etc.,

I'd suggest Intel IA-32 software developer manual is a great friend in the technical aspects.

This is when I worked with legacy proprietary BIOS for modern UEFI BIOSs I have no dev experience but I think it is init-d the similar way.

When early in the system initialization, you got no video no memory so usually use few bytes of CPU registers to hold datas.
Sometimes, PCIe device scratch registers.
Intel ITP jtag is normally used for debugging.
Sometimes, my preferred method of debugging is configure serial port as early as possible (even before DRAM initialization) and use serial console as a way of debugging.

Thanks.,