First steps in bare-metal programming using UEFI
LaSombra
209 points
38 comments
November 06, 2026
Related Discussions
Found 5 related stories in 125.1ms across 11,878 title embeddings via pgvector HNSW
- Code-execution flaw in UEFI firmware threatens most servers on planet Earth DamnInteresting · 84 pts · October 27, 2026 · 51% similar
- GEFS on OpenBSD: A Early Preview sippingabonedry · 113 pts · September 15, 2026 · 49% similar
- Is x86 ready to ACE it? mfiguiere · 45 pts · July 14, 2026 · 45% similar
- Fixing a bricked Framework laptop jp_sc · 396 pts · August 18, 2026 · 45% similar
- How to bring up the Linux Kernel on a new platform WerWolv · 20 pts · September 03, 2026 · 44% similar
Discussion Highlights (14 comments)
joeinfo888
Had been looking for this. Thank you
the_panopticon
For "Get used to the lack of a C standard library" mentioned in https://kevinboone.me/efitest4.html there's always https://github.com/tianocore/edk2-libc . And on "Be aware of the Windows-ness of EFI" commentary the resemblance to Windows coding style https://computernewb.com/~lily/files/Documents/NTDesignWorkb... is no accident. We leveraged this coding methodology as we evolved the original Intel Boot Initiative then EFI and then UEFI code and specification https://www.intel.com/content/dam/www/public/us/en/documents...
edoceo
This guide is fantastic for getting rolling in the UEFI space. I used this as one of the references when building a bootloader with Zig. Has its own set of issue, especially that 16bit character situation. Once you dig into those there are a bunch of sharp edges, or maybe it's just that that EFI environment is so weird compared to typical Linux system or application development.
kragen
(Although this comment discusses an AI-written project, the comment itself is entirely human-written.) It's probably worth pointing out that, unless you're writing a replacement for GRUB, Multiboot2 is a reasonable alternative to building a UEFI PE32+ image, and it permits you to still call UEFI services: https://www.gnu.org/software/grub/manual/multiboot2/multiboo... https://wiki.osdev.org/Multiboot I was pleased last week that I could elicit enough of a UEFI environment from Opus 5.5 to be able to build an UEFI application without enormous, un-auditable dependencies like gnu-efi. Claude distilled the relevant parts of the UEFI interface into a 289-line header file. The example application just displays the keyboard and mouse events on a UEFI framebuffer using a vendored pixel font, thus the name "inputmon": http://canonical.org/~kragen/sw/inputmon-3.tar.gz The Makefile includes a "run" target to boot it under QEMU with the OVMF implementation of UEFI. (One fairly surprising feature of all this is that, not counting the time Claude was waiting for me, it took the model a total of about 7 minutes to write and test this. These 7 minutes were spread over almost 15 hours because I ran out of tokens and spent time thinking. This might be a good example of a case where an LLM is literally a million times more productive than a human programmer: the task is algorithmically trivial, and it doesn't involve difficult engineering tradeoffs, but involves deep knowledge of a pile of obfuscated recondite interfaces that are publicly documented and widely used by published open-source software. It is something I've wanted to do for 7 million minutes.) I'm hoping I can get an in-browser demo of inputmon working next week, but that's probably going to involve doing some surgery on Bochs in order to get an amd64-compatible virtual machine that doesn't require multithreading the way QEMU does. Inputmon does have the enormous, un-auditable dependency of LLVM and Clang, but that's a horror I'm already resigned to. But with clang, lld, and make, you can build the image from source, and with QEMU and OVMF you can run it in a virtual machine. I think it's a little bit debatable to call UEFI "bare metal" (Boone responds: "this is a fair criticism"), and I'm particularly skeptical of Boone's claim that you can guarantee microsecond response times in the face of SMM, but whatever.
kevin_thibedeau
> The linker won’t complain if your code calls functions that don’t exist – it will just mark them as external, expecting them to be provided by some other code. But they won’t be, and the program will just crash when it calls one of these missing functions. You can verify no external symbols remain after linkage with: nm -D --undefined-only. This can be incorporated into a build script to verify the binary is valid.
SilentM68
Wish there was a noobie-friendly book e.g.,pdf, epub showing how to do this as is and assembly.
brcmthrowaway
Does anyone still use UEFI? If I start looking into the latest and greatest Qualcomm Nuvia ARM Windows laptops, does it use UEFI? Or regular BIOS?
tremon
Is it real bare-metal if you're using UEFI, though?
erminpour
More posts and projects like this please!
0c3ca83
It's like programming an overengineered DOS.
mrlonglong
Yikes. UEFI is way worse than I thought it was. Best thing to do with it is treat it as a bootloader and use something else a lot more sane than UEFI. Dare I live in hope that a newer revision will use 8 bit UTF and better conventions.
hocusPokeUs
Other cool uefi programming resources: Irc client in uefi: https://github.com/codyd51/uefirc UEFI library the irc client relies on: https://github.com/rust-osdev/uefi-rs No more separate GRUB/boot loader code paths needed; boot Linux from UEFI by loading a kernel: https://pretalx.com/devconf-cz-2024/talk/W3AVCT/ Have noodled around with a side-project generating an entire system from boot loader via LLMs but haven't had energy for it given job is the same headspace that needs to be ignored once in a while to not burnout; ultimately want to boot a model of my Linux use (am using bpf to plan and model everything possible and convert it to a compute schedule for sched_ext) and just have a kernel <> model architecture For security am considering how to embed in the model various authentication obligations to block access to certain blocks of memory without confirmation via webcam and key or something
JdeBP
Rod Smith and the OSDev Wiki went here, sometimes word for word, years before: * https://rodsbooks.com/efi-programming/ * https://wiki.osdev.org/GNU-EFI Of course, they both assume GCC on Linux. Change either one of those, and it is a wholly different kettle of fish. Both NetBSD and FreeBSD, for examples, come with an EFI development environment in base, squirreled away in /usr/src/boot in the case of FreeBSD. They have to, because they need to be able to build their own EFI boot loaders. NetBSD targets more than Intel processor architectures for EFI, moreover. (NetBSD can boot via EFI on ARM CPUs, for instance.)
mlfreeman
You can even use C# https://github.com/MichalStrehovsky/zerosharp https://github.com/MichalStrehovsky/uefimaze Not my creation but on my list to poke at one day soon