--- title: First steps in bare-metal programming using UEFI | daily.dev description: This is an index page linking a five-part series on bare-metal UEFI programming for PC-type computers using a Linux workstation. The series targets experienced... canonical: https://daily.dev/posts/first-steps-in-bare-metal-programming-using-uefi-qodgtbkxg twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: First steps in bare-metal programming using UEFI | daily.dev og:description: This is an index page linking a five-part series on bare-metal UEFI programming for PC-type computers using a Linux workstation. The series targets experienced... og:url: https://daily.dev/posts/first-steps-in-bare-metal-programming-using-uefi-qodgtbkxg og:image: https://api.daily.dev/og/posts/qOdGtBKXg.png og:image:alt: First steps in bare-metal programming using UEFI og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # First steps in bare-metal programming using UEFI **[Hacker News](https://daily.dev/sources/hn)** · 1 min read · 1 upvotes · 0 comments ## Summary This is an index page linking a five-part series on bare-metal UEFI programming for PC-type computers using a Linux workstation. The series targets experienced Linux developers who have no prior UEFI knowledge. It covers compiling and linking, the EFI system partition, creating a bootable DVD or USB image, a pragmatic digression, and handling files with the Simple File Protocol. The author notes the articles should be read in order since each depends on the previous one. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What topics does a bare-metal UEFI programming tutorial series need to cover for Linux developers? A complete bare-metal UEFI tutorial series for Linux developers covers compiling and linking code, understanding the EFI system partition, creating a bootable DVD or USB flash image, and handling files using the Simple File Protocol. The series is designed for experienced Linux developers who have no prior UEFI knowledge, with each part building on the previous one. _daily.dev surfaces follow-up guides for developers working through bare-metal UEFI programming step by step._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 29 comments across hackernews (as of 2026-11-06). **TL;DR:** Commenters generally welcome the UEFI tutorial series as a useful practical resource, while a large side-thread turns into a technical critique of UEFI's design choices (UTF-16, VFAT) inherited from Windows conventions. **Sentiment:** 35% positive · 40% mixed · 25% skeptical **The case for** - Several found the series genuinely useful for getting started with UEFI/bootloader development, including one who used it while building a bootloader in Zig. - The practical digression in Part 4 about the gap between 'it builds' and 'it boots' was specifically praised. - One commenter added detailed practical tips (memory map key staleness, QEMU/OVMF quirks) extending the tutorial's value. **The pushback** - Many criticized core UEFI design choices as bad legacy decisions, especially UTF-16 string encoding and the VFAT filesystem requirement. - Some debated whether UEFI can really be called 'bare metal' given how much environment/services it provides before ExitBootServices. - One noted a severe CVE in EDK II that users should watch out for. - One comment was dismissive, flagging apparent LLM-generated text as unwelcome. **By community** - hackernews (mixed): Practical appreciation for the tutorial coexists with a long, heated technical tangent criticizing UEFI's UTF-16 and VFAT design legacy. **Hottest debate:** Whether UEFI's inherited Windows-style design choices (UTF-16, VFAT) were justified or represent lasting technical debt, and whether UEFI even deserves the 'bare metal' label. **Open questions** - Is there a beginner-friendly book or structured resource (PDF/epub) covering this material alongside assembly? - Will Microsoft/UEFI ever move away from UTF-16 toward UTF-8? **Highlights** > I think "leveraged this coding methodology" is an unjustifiably positive way to describe the results of the process. I think "spread this disease" would be more accurate. UTF-16 strings, really? VFAT? PE32+ is maybe justifiable (I'd prefer ELF, but that's because it's more familiar, not because it's actually better), but VFAT? And even in 01998 it should have been apparent that UTF-16 was not a sane format for strings, much less in 02005 when the EFI → UEFI transition happened. To me, UEFI is like "leveraging the waste disposal methodology" of dumping your toxic waste in a lake. Yes, it's more convenient for you, but it does lasting damage and causes years of suffering for millions of people; and eventually somebody else has to clean up your mess, at far greater cost than if you'd just done something sensible to begin with. I could probably say the same thing about X-Windows. > — [kragen on hackernews · 2 comments](https://news.ycombinator.com/item?id=50397097) > One thing I would add to the intro: calling this "bare metal" is almost a cheat compared to the BIOS days. You start with a working console, a memory map, and even a file system service; then ExitBootServices takes every bit of that away. That is the real bare-metal moment, and it is exactly where a series like this earns its keep. Two things that always bite people on this path: - The memory map key returned by GetMemoryMap goes stale the moment anything allocates. Hand the freshly fetched key straight to ExitBootServices; if it comes back EFI_INVALID_PARAMETER, that is why. The firmware is right, even though it feels unfair. - QEMU with OVMF (code and vars as separate pflash files) gives a far faster edit-run loop than rebooting hardware, and it is stricter about struct layout and protocol revisions than most real firmware. When something boots on metal but not in OVMF, it is almost always an alignment or version assumption, not a QEMU bug. The pragmatic digression in Part 4 was a good call. The gap between "it built" and "it boots" is where most of the learning (and quitting) happens. > — [alexkampler on hackernews · 2 comments](https://news.ycombinator.com/item?id=50395647) > 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. > — [mrlonglong on hackernews](https://news.ycombinator.com/item?id=50398967) > (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. > — [kragen on hackernews · 1 comments](https://news.ycombinator.com/item?id=50396963) > > Is it real bare-metal if you're using UEFI, though? If I'm not mistaken, the "bare metal" part refers to how directly you can touch it once control passes to your code. So definitely qualifies imho. Not whether a 'glorified bootloader' burned some CPU cycles before that. The "bare metal" qualifier goes away if underlying OS prevents your code from touching the hardware directly. > — [RetroTechie on hackernews](https://news.ycombinator.com/item?id=50398926) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50394855) · 151 points · 29 comments ## Similar posts on daily.dev - [Play Games In UEFI…to Access Your Computer](https://daily.dev/posts/play-games-in-uefi-to-access-your-computer-nyku914tp) · Hackaday · 2 upvotes · 1 comments - [Building Your Own Operating System From Scratch \(A Practical Getting-Started Guide\)](https://daily.dev/posts/building-your-own-operating-system-from-scratch-a-practical-getting-started-guide--bcelcqpq7) · Medium · 0 upvotes · 0 comments --- Tags: [#linux](https://daily.dev/tags/linux), [#c](https://daily.dev/tags/c) [View this post on daily.dev](https://daily.dev/posts/first-steps-in-bare-metal-programming-using-uefi-qodgtbkxg) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"First steps in bare-metal programming using UEFI","url":"https://daily.dev/posts/first-steps-in-bare-metal-programming-using-uefi-qodgtbkxg","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/first-steps-in-bare-metal-programming-using-uefi-qodgtbkxg"},"datePublished":"2026-11-06T18:16:14.890Z","dateModified":"2026-11-06T22:47:20.741Z","description":"This is an index page linking a five-part series on bare-metal UEFI programming for PC-type computers using a Linux workstation. The series targets experienced...","image":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","thumbnailUrl":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/first-steps-in-bare-metal-programming-using-uefi-qodgtbkxg","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux,c","timeRequired":"PT1M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"First steps in bare-metal programming using UEFI"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/first-steps-in-bare-metal-programming-using-uefi-qodgtbkxg#faq","mainEntity":[{"@type":"Question","name":"What topics does a bare-metal UEFI programming tutorial series need to cover for Linux developers?","acceptedAnswer":{"@type":"Answer","text":"A complete bare-metal UEFI tutorial series for Linux developers covers compiling and linking code, understanding the EFI system partition, creating a bootable DVD or USB flash image, and handling files using the Simple File Protocol. The series is designed for experienced Linux developers who have no prior UEFI knowledge, with each part building on the previous one. daily.dev surfaces follow-up guides for developers working through bare-metal UEFI programming step by step."}}]} ```