[nickelpro]

UEFI is an interface implemented by firmware (literally, Unified Extensible Firmware Interface), it's not the firmware itself. Saying "it starts the machine" is a bit of a nomenclature faux pas. The firmware starts the machine, you talk to the firmware via UEFI.

This post skips all the interesting things in the modern firmware dance. Not the least of which is when you call ExitBootServices() you're already in long mode. There's no need for the journey through real and protected.

[1oooqooq]

firmwares are the real IoT nobody talks about that that actually happened. infinite little computers and code churning away from view. and not being updated.

next 'snowden leaks' will have that word on every page.

[caycep]

at least from whatever's been published, a good chunk of NSA's tools exploit low level firmware bugs like this...

also wondering how great my Asrock firmware is vs. say the bog standard Lenovo (i assume Apple is the one company that's expended significant thought into locking this process down)

[tonetegeatinst]

Worse is how little information exists on firmware or how development for firmware works.

Its certainly not something regularly taught in higher education.

[anthomtb]

In a past life I held the title Firmware Engineer. The day-to-day development process did not differ from subsequent positions as a Software Engineer. Write-Compile-Test-Repeat. Then put it up for review so your colleagues can skewer it, or, on rare occasion, offer considerate and thorough feedback.

Firmware development is indeed taught in higher education. But not under the name "Firmware". It will be an "embedded systems" course or series of courses. At least in my experience, those courses are run by the Electrical Engineering department and the average Computer Science student stays far away from them.

[mbac32768]

How do you test stuff that's deployed to firmware? At least when it comes to normie software your Linux or Mac box resembles the server you deploy to. And you can close the distance quite a bit with Docker.

But firmware? Totally different. FreeRTOS does have a POSIX backend, which helps some. Maybe you can run it under a hardware emulator. But it seems like lots of the stuff you want to test isn't really testable from the perspective of what a typical dev knows.

A lot of firmware dev iteration seems to be build -> flash -> watch serial connection for debug prints.

[anthomtb]

> A lot of firmware dev iteration seems to be build -> flash -> watch serial connection for debug prints.

Serial port? Maybe for the fancy folks. Us lunch-pail types would find an unused GPIO, blue-wire an LED, and blink out a code of your choosing.

Okay, I never actually had to blink an LED but it was in my bag of tricks. The real golden-ticket to debugging embedded devices was a development kit with JTAG. JTAG, coupled with expensive additional hardware and equally expensive software license, gave you a gdb-like interface for debug. Breakpoints, stack traces, all the good stuff you take for granted when working with Windows, Linux, or those ugly abominations we call web browsers.

Emulators were also a thing, especially if your product had a custom ASIC and you needed pre-silicon development. But I didn't use them a lot myself and it seemed like by the time you had your emulation environment setup, there was 1st gen silicon and a debug board sitting at your desk.

[waste_monk]

I'm not a firmware dev but the one's I've seen working usually have all sorts of fancy test kits, debug instrumentation, Software (chip scope?), etc. to debug with, not just relying on print debugging.

Not to say it isn't a valid way to debug, but there are definately better options available.

[tonetegeatinst]

As someone in the security field, who is currently in a security degree program...I have a major overlap with the EE and computer engineering degree requirements.

Iv dabbled in some basic MIPS assembly and some microcontroller programming but don't consider that as complicated as boot level firmware or say the firmware that controls complex stuff.

I view embedded as the closest I will ever get to actual hardware engineering and it shocks me how complex everything is.

[QuiEgo]

If you're curious go walk through the bootloaders of an embedded platform, they serve roughly the same role as firmware that implements UEFI on traditional x86 systems.

Example, start with bl1 (first stage boot loader) for a Rasberry Pi here:

https://github.com/raspberrypi/arm-trusted-firmware

The Pi's hardware (register map, etc) is well documented so it's a good way to learn this stuff.

[jdsnape]

Maybe not on compsci? but when I did electronic engineering it was covered as part of our embedded systems course.

There’s quite a lot of info out there on UEFI, and tiano core is open source. I taught myself enough to implement a small game you had to solve to be able to boot your machine, for example :)

[7bit]

I'm currently trying to learn more about how the boot process works, specifically with UEFI. Yesterday I watched a video on how to program a UEFI bootloader so I was happy when I saw this article this morning.

The article jumps over so many steps and leaves out so many mechanics that I had to stop reading, because it just opened more and more questions without closing any. For example, right at the beginning:

> Right after reset the CPU jumps to a special address called the reset vector at 0xFFFFFFF0. Think of it as a permanent bookmark that says “start here.” There is room for almost nothing at that address, so manufacturers put a short jump there that passes control to the firmware on your motherboard.

What does that even mean? It jumps there means that it executed whatever is at that address, but it failed to explain how the instruction at that location is even put there in the first place.

Reading a little more I truly am confused for who this was even written. It seems you need a lot of prior knowledge to understand what the author talks about and then it also makes me wonder what additional information this article conveys if you already can fill in the gaps.

[II2II]

You use the toggle switches on the front panel to set the address to the reset vector and the data to the jump instruction, press a button to load the jump instruction into that address in memory, the press a button to reset the CPU.

More seriously, at least for modern systems: the engineers who designed the computer created a memory map that defined which hardware can be found where. They simply ensured that the reset vector would point to an area of non-volatile memory that can be read directly (e.g. an EEPROM would work since you feed it an address and it returns data, much like RAM). That jump would be to somewhere else in non-volatile memory, an area that would have enough space for the code to continue the initialization process. You would have to ask someone more familiar with CPU architecture why they use an indirect approach. My guess is that many CPU architectures define a vector table, which is a list of places the CPU will jump to when various contditions are met (e.g. an interrupt, or reset).

[mmh0000]

Would love to see the video you're referencing. Mind providing a link?

[7bit]

Its the series from Queso Fuego. Too lazy to get the link right now :)

[MonaroVXR]

Where do I read more about this?

[heromal]

Here's one source: https://depletionmode.com/uefi-boot.html

[ghostpepper]

https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpX...

The ost2.fyi courses are all high quality