Question If the UEFI POSTs and loads the OS, then what launches the UEFI Itself in the first place ?

[AtomikDjakareh_32G]

So, I know the UEFI is responsible for POSTing then loading the machine's OS... But then, what loads the UEFI itself up in the first place? Does it have its own tiny special boot loader?

 

[white.a.drew]

So, I know the UEFI is responsible for POSTing then loading the machine's OS... But then, what loads the UEFI itself up in the first place? Does it have its own tiny special boot loader?

Bios launches and runs uefi

 

[hotaru.hino]

Every CPU has something called a "Reset vector." This is basically the first address in memory where instructions loaded and ran.

Note that "memory" can be any memory device and not necessarily RAM. In this case, the BIOS/UEFI flash chip.

 

[drea.drechsler]

As I understand it:

Correctly, in UEFI the CPU reset vector points to the security phase of the boot process in UEFI (BIOS) which is the earliest phase of booting and acts as a root of trust. After that it initializes pre-EFI environment which includes memory and chipset initialization (the rest of POST?). Before this, it was using CPU resources only and operating out of CPU cache but after this it can use main memory and load initial drivers (from firmware?), initiate EFI runtime services and search for EFI partition to load additional drivers including display (for the console?) .

With the hardwares initialized and drivers to access them loaded the boot dispatcher can now load the boot manager (located in the EFI partition) which contains the variables to facilitate OS startup (including location of the OS partition). For transient OS services (booting from a USB flash drive for instance) there are some differences.

That's probably grossly oversimplified so...more here:
https://edk2-docs.gitbook.io/edk-ii-build-specification/2_design_discussion/23_boot_sequence
and especially here:
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

 

[white.a.drew]

Every CPU has something called a "Reset vector." This is basically the first address in memory where instructions loaded and ran.

Note that "memory" can be any memory device and not necessarily RAM. In this case, the BIOS/UEFI flash chip.

As I understand it:

Correctly, in UEFI the CPU reset vector points to the security phase of the boot process in UEFI (BIOS) which is the earliest phase of booting and acts as a root of trust. After that it initializes pre-EFI environment which includes memory and chipset initialization (the rest of POST?). Before this, it was using CPU resources only and operating out of CPU cache but after this it can use main memory and load initial drivers (from firmware?), initiate EFI runtime services and search for EFI partition to load additional drivers including display (for the console?) .

With the hardwares initialized and drivers to access them loaded the boot dispatcher can now load the boot manager (located in the EFI partition) which contains the variables to facilitate OS startup (including location of the OS partition). For transient OS services (booting from a USB flash drive for instance) there are some differences.

That's probably grossly oversimplified so...more here:
https://edk2-docs.gitbook.io/edk-ii-build-specification/2_design_discussion/23_boot_sequence
and especially here:
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

Lol basically the same as what I said but longer the bios controls the whole system without it you have nothing thanks people.

 

[drea.drechsler]

Lol basically the same as what I said but longer the bios controls the whole system without it you have nothing thanks people.

Not trying to be pedantic but correctly even though we think of it as one and frequently call it that it's not BIOS anymore, it's a UEFI. I think it's more correct to refer to it as "firmware" for what's controlling things prior to the EFI runtime environment be established.

That's kind of important because the EFI runtime evironment is a very simple OS in it's own right. You can boot to EFI and get a command line, much like DOS.

 

[hotaru.hino]

Lol basically the same as what I said but longer the bios controls the whole system without it you have nothing thanks people.

For one BIOS doesn't exist in a system with UEFI. UEFI replaces BIOS. But in general, both are types of firmware as @drea.drechsler said. For another, since OP is asking what could be construed as a general computer systems related question, I'd rather give them an answer that explains how computers work in general. Because you know, my FitBit doesn't have a BIOS/UEFI. The SNES sitting in my closest doesn't have BIOS/UEFI. So how do those things boot up? And to be really pedantic, "BIOS" is specifically the name of the firmware used in IBM PC compatible computers. I've worked with bare metal software and we don't call what you'd call BIOS "BIOS."

Also, in this use case anyway, motherboard firmware does not control the computer per se. It initializes the hardware, then boot it into the OS. Once the OS is booted, the OS has control of the computer. The firmware is no longer running at that point. And even then, the firmware doesn't really have the highest authority in systems. For example, in Apple computers, the T2 chip determines what gets initialized and what not before the CPU even has a chance to run anything.

 

[drea.drechsler]

...
Also, in this use case anyway, motherboard firmware does not control the computer per se. It initializes the hardware, then boot it into the OS. Once the OS is booted, the OS has control of the computer. ...

More correctly, once the firmware is done it "boots", or initializes, the EFI. The EFI loads run-time components (drivers) so it can boot the OS. This explains the function of the EFI partition: it holds all those drivers and components that can't be stored in the firmware. Probably part of what makes it "extensible". And (something I just learned) it seems it doesn't really step completely out of the way as there's an "after life" component that helps in storing the system state during shutdown.

I seem to remember something about the T2 chip with Apple...IIRC it used to be considered one of the reasons it was more secure. But that was in the day of MBR and the boot vector pointing to the boot sector of the hard drive and executing whatever code it found there. All changed with UEFI and GPT and the reason running with Secure Boot is so important if you want to minimize exposure to root kits.

 

[hotaru.hino]

If we're going to try to get precisely accurate: UEFI is an interface between the firmware and whatever takes over the computer afterwards, typically an OS.

So really we've been going about it the wrong way, but I don't think it really matters that much since it'd be like saying "I'm targeting the Skylake microarchitecture" rather than "I'm targeting x86-64"

 

[AtomikDjakareh_32G]

Very informative. Thanks everyone.

 

[CountMike]

BIOS is a chip and UEFI is way it works but it's not only graphic representation as there were BIOS types with GUI using mouse long, long time ago but were not UEFI in any way.

 

[Colif]

So, I know the UEFI is responsible for POSTing then loading the machine's OS... But then, what loads the UEFI itself up in the first place?

CPU boots the system.

AMD have an isolated core on the CPU that boots, creates & manages the environment that the BIOS/UEFI runs in. I think Intel uses the Intel Management Engine to do same things.

AMD uses the Platform Security Processor that is a ARM core on the CPU that is completely separate to the cores that you have access to. It sets up Secure boot and is also where the TPM is.

PC cannot boot without a CPU (bets someone can prove him wrong)

 

[hotaru.hino]

CPU boots the system.

AMD have an isolated core on the CPU that boots, creates & manages the environment that the BIOS/UEFI runs in. I think Intel uses the Intel Management Engine to do same things.

AMD uses the Platform Security Processor that is a ARM core on the CPU that is completely separate to the cores that you have access to. It sets up Secure boot and is also where the TPM is.

PC cannot boot without a CPU (bets someone can prove him wrong)

I believe the security platform's job is solely to verify that the firmware on the motherboard is signed, plus a few other things to ensure the system wasn't tampered with in some way. Once everything is hunky dory, it turns on the CPU, which then executes the reset vector, which is the motherboard's firmware.

 

[CountMike]

CPU boots the system.

AMD have an isolated core on the CPU that boots, creates & manages the environment that the BIOS/UEFI runs in. I think Intel uses the Intel Management Engine to do same things.

AMD uses the Platform Security Processor that is a ARM core on the CPU that is completely separate to the cores that you have access to. It sets up Secure boot and is also where the TPM is.

PC cannot boot without a CPU (bets someone can prove him wrong)

Bet's on, what about MB that can update BIOS even without a CPU present ?

 

[hotaru.hino]

Bet's on, what about MB that can update BIOS even without a CPU present ?

It technically doesn't boot

 

[CountMike]

It technically doesn't boot

Maybe not full boot but it's doing same thing you can do with SW and that also meas it runs some OS in there no matter how small or limited in scope it is, It can read an USB, see and use files on it and reprogram BIOS chip. That's quite a bit of work without some kind of CPU, memory and I/O.

 

[drea.drechsler]

Maybe not full boot but it's doing same thing you can do with SW and that also meas it runs some OS in there no matter how small or limited in scope it is, It can read an USB, see and use files on it and reprogram BIOS chip. That's quite a bit of work without some kind of CPU, memory and I/O.

The question is: what exactly is doing all that? I tend to think it's something that operates like an EPROM programmer which also does not use any of the firmware (BIOS, whatever) or UEFI services to do it's thing.

 

[hotaru.hino]

Maybe not full boot but it's doing same thing you can do with SW and that also meas it runs some OS in there no matter how small or limited in scope it is, It can read an USB, see and use files on it and reprogram BIOS chip. That's quite a bit of work without some kind of CPU, memory and I/O.

You don't need an OS to read a USB drive, the file system it has, or to reprogram flash. Though those certainly help.

I was able to make a bootloader with a firmware update thing over IrDA for one of my work projects. Obviously the USB protocol is more complicated but it's not that much so.

I also think most firmware lives on some sort of SPI chip, and that interface is easy to work with.

 

[LinuxDevice]

Every motherboard has a bit of an orchestra trying to set up power rails and clocks in a coordinated way when power applies. There is usually an embedded microprocessor responsible for this, and the software in combination with that is the BIOS. The UEFI itself is pure software, but is kind of fascinating in comparison to the old style BIOS which used Master Boot Record (MBR) instead of UEFI. Some comparison might be of interest.

Old style BIOS (and to some extent even UEFI) has what someone else mentions: Once power rails and clocks are set up, it transfers execution to some location with certain prerequisites being set up. The UEFI and the old style MBR have different assumptions about what is set up, but they both have the same concept of a generic starting point (an interrupt vector is what tells the processor to execute an IRQ table, and essentially this is the heart of an operating system, and both MBR and UEFI are mini operating systems).

What differs about UEFI (other than hard drives having different partition schemes), and what makes it interesting, is that it is more object oriented. Once started UEFI has an "abstraction" layer of firmware. This abstraction layer is custom for each BIOS and motherboard, but it sets up a "standard" environment with a more object oriented environment. The MBR was very specific and not object oriented (there is no concept of abstraction to a standard environment where anyone could write a generic program to some interface standard without knowing the code launching that program). UEFI, once the abstraction layer is complete, becomes pretty much generic and anyone could write code which "just plugs in and works" to launch their operating system (which itself is more or less the bootloader attempting to kill itself by overwriting with some operating system kernel).

UEFI is more or less the two stages of abstraction of firmware to a generic modular environment, followed by a subprogram, e.g., the bootloader, while MBR directly executes the firmware and bootloader together. Both start the same way, with the BIOS setting up rails and clocks, then transferring execution to some standard location (though the location and what is set up will differ, they are both started with a hardware interrupt). MBR is messy, UEFI is modular, both are started more or less the same way by the BIOS.

 

[kerberos_20]

UEFI can act as operating system aswell...you can also run apps in it (without any OS), including games
it has command line (similar to linux shell), but unlike linux, UEFI needs compiled apps :/

 

[CountMike]

UEFI can act as operating system aswell...you can also run apps in it (without any OS), including games
it has command line (similar to linux shell), but unlike linux, UEFI needs compiled apps :/

Exactly, some can even connect to internet to download and update BIOS. Even some Legacy BIOS could.

 

[CountMike]

Note that "memory" can be any memory device and not necessarily RAM. In this case, the BIOS/UEFI flash chip.

CMOS is just volatile memory memory, (pretty fast too) kept running by it's battery.
Electrically speaking, BIOS chip is EEPROM.

 

[kerberos_20]

CMOS is just volatile memory memory, (pretty fast too) kept running by it's battery.
Electrically speaking, BIOS chip is EEPROM.

technicaly speaking, UEFI doesnt use CMOS RAM anymore, its using NVRAM, not battery powered, CMOS is still used in RTC, thats why removing batery mostly has nothing to do with reseting uefi settings

 

[BFG-9000]

Yep, UEFI boards still have a CMOS RAM and battery but only the time and some legacy/CSM things are stored in there. The UEFI settings are indeed stored in a partition of NVRAM just like in a router, and "CMOS CLR" or reset is erasing that partition.

It doesn't matter if you call it BIOS or CFE or U-Boot, its job is to bootstrap itself, make sure things are OK, then look for an OS to load

The story of how Compaq came to be is very interesting. Even though IBM published the source code of its BIOS in the manual for the 5150, Compaq put engineers into a clean room with only the instructions to write software to do what a BIOS was supposed to do, so their BIOS could be proven to be an independent work and not reverse engineered. Thus, IBM copyrights were not violated and cheap "IBM Compatible" PCs became a thing in 1982.

UEFI is different.

What is also interesting is how Intel's Management Engine (or AMD's equivalent Platform Security Processor) are complete mini computers with their own microprocessor and operating system that have direct access to network ports and system memory, which are always on whenever there is power, and perform the bootstrapping function to initialize the x86 cores and copy the UEFI to DRAM before starting the UEFI itself. So to answer your question, it's this hidden computer in a computer that loads the UEFI.

This computer operates below ring-0 so can read or write anything in memory without the kernel knowing about it, and copy/send or modify TCP/IP network packets bypassing the OS and any firewall. Even when the PC is asleep or off. What could possibly go wrong?

 

[kerberos_20]

This computer operates below ring-0 so can read or write anything in memory without the kernel knowing about it, and copy/send or modify TCP/IP network packets bypassing the OS and any firewall. Even when the PC is asleep or off. What could possibly go wrong?

im not sure about intel side, but on amd, it provides some passive security services like memory enryption and whatnot, nothing like on intel side where it can get exploited to control your PC, on amd, its passive, and any external activity would crash PC