HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
linuxboot
heads
Makefile2017–2026
linuxboot / heads

heads

A minimal Linux that runs as a coreboot or LinuxBoot(UEFI's DXE replacement) ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.

11Distinct people
15Mentions
1Explicit recommenders
1.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A minimal Linux that runs as a coreboot or LinuxBoot(UEFI's DXE replacement) ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Wow, this is awesome! This relates to work I've been doing with the [Heads](https://osresearch.net/) project. Specifically I got a PR merged for the first ChromeOS Port using…

cwiggs used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year15 dated mentions

Observed mentions: 2017-04-06 20:30:42 UTC to 2026-10-24 23:16:49 UTC.

0123452017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC110
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC505

What Hacker News says

15 sources
cwiggs·Oct 15, 2026Recommendation phrase
Wow, this is awesome! This relates to work I've been doing with the [Heads](https://osresearch.net/) project. Specifically I got a PR merged for the first ChromeOS Port using MrChromebox's code as an upstream dependency: https://github.com/linuxboot/heads/pull/2133 I'm now working on the 2nd ChromeOS device in this PR right now: https://github.com/linuxboot/heads/pull/2225 And there is a 3rd port by someone else: https://github.com/linuxboot/heads/pull/2219 I'm surprised Libreboot was able to add all the ChromeOS devices at once, Just adding the 2 ports for Heads hasn't been easy, although I'm not an expert when it comes to Coreboot. Anyway, I love seeing more support for Chromebooks, they are great devices. Funny enough my Acer Chromebook (Kano) is now more open and more secure than my Framework 13s.
In Libreboot 26.10 "Ominous Olive" released with UEFI, Chromebook support
It does. They obscure the usage of non-free hardware/firmware by not shipping it as part of the OS, but as a bundle on separate flash storage that is loaded into the OS by initrd. That blob is updatable as "firmware". The 100% free open-source is just marketing. It's just for the OS. A lot of the hardware and firmware is proprietary. https://github.com/linuxboot/heads/blob/c859c28b88b7bc197c16... https://forums.puri.sm/t/the-librem-5-blob-list/28815/26
In Your phone is about to stop being yours
I'm surprised that the author doesn't mention Pureboot [0] or even Heads [1], the most user-friendly [2] way to use TPM on Linux and authenticate the boot process along with /root, /boot directories. Also, there is no Microsoft involved in my laptop, i.e., the author's statement > Microsoft's certificates are basically built into all of today's PCs is wrong. I enjoy the coreboot with Heads on my Librem 14 with my own keys. [0] https://docs.puri.sm/PureBoot.html [1] https://github.com/osresearch/heads [2] https://puri.sm/posts/pureboot-101-first-boot-first-update-a...
In Authenticated Boot and Disk Encryption on Linux (2021)
Disclaimer: I didn't fully read the article yet. I wanted to mention the excellent HEADS project (as in the other side of TAILS): https://github.com/osresearch/heads This talk is great: https://trmm.net/Heads_33c3 I remember when UEFI became a thing and people were complaining in linux forums that the keys are controlled by the manufacturers and 'the whole thing is a ploy by microsoft to kill linux' (UEFI is just a convoluted standard way to write BIOS in a certain way). Now we can control the keys, all we need to do is kick UEFI to the curb and use linux from BIOS all the way to the DE/WM (coreboot..). Turns out we can turn the boot process into a chain of kexec's and simplify everything greatly.
In Geeking Out with UEFI
>How does GP know that everything is actually being provided unmodified, without any backdoors? They don't need to. That is precisely the point. The entire software stack is open source and reproducible (except a few KBs of Intel ME). As a press release, the linked post is brief. If you wish to read more on the technical aspects, here are all the constituent projects: https://coreboot.org/ https://github.com/osresearch/heads/ https://github.com/corna/me_cleaner https://github.com/nitrokey A good talk if you prefer video: https://media.ccc.de/v/33c3-8314-bootstraping_a_slightly_mor...
In NitroPad: Secure Laptop with Tamper Detection
> I can't say I know how secure or safe this is going to be without examining it in detail myself I've been working on something about Heads (a minimal Linux-based secure bootloader) since January, too. And I can say the boot verification used by Heads is sound and solid. The implementation is basically a verified/measured boot scheme with TOTP. During initialization, you generate a random TOTP key, add the key to your TOTP authentication device (e.g. Google Authenticator on mobile phone), and "seal" the key in your TPM, along with your boot "measurements". During the boot process, these "measurements", or the SHA hashes of various information/configuration about hardware, software and firmware, is being passed to the TPM. If the configuration has changed, the TPM will refuse to release the TOTP secret, otherwise, the TOTP key is released
Read the rest
, then used to calculate a random number by a shell script in Heads. If the number on your mobile phone matches with the number on the screen, then it proves the system is not being tampered. Read the code here: https://github.com/osresearch/heads/blob/584c07042ef4898de52... https://github.com/osresearch/heads/blob/584c07042ef4898de52... (yes, all shell scripts... I'm not sure whether this is a security issue, but this design is probably inspired by the initrd/sysvinit shell scripts) Obviously, it means every time you boot your computer, it requires you to check the 6-digit code against your phone, before it boots the actual Linux kernel, or enter your full-disk encryption key. To me, Librem Key improves it, by automating the process (as Nitrokey has TOTP functionality already), and using a simple protocol to automate the challenge-response verification. If you want to learn more, make sure to read about Heads first. https://github.com/osresearch/heads This presentation is a good start. https://trmm.net/Heads_33c3 Attack Vectors: 1. The trustworthiness and security of the TPM. The Free Software community has historically rejected them because of the DRM aspect of "trusted" computing. But to this day, the complete DRM dystopia (where all the proprietary software is running inside Intel Management Engine, and performs DRM-related cryptography in TPM blackboxes, was it called Microsoft Palladium?) didn't turn out to be a threat, fortunately. So now even RMS acknowledged that there is no actual reason to not implementing free software security tools based on TPM. Another reason is potential backdoor, but even there is a backdoor, using it still improves security, compared to completely unprotected machines. In the future, perhaps there can be Free Hardware TPM, but not in the foreseeable future, and Heads's usage of TPM is still a big step towards security. 2. Completeness of measurements. If some software/hardware changes are not measured, or can be replayed by the attacker, the attack will not be detected. But the measurements are done collaterally by coreboot in early boot, and Heads in later boot, and to me is fairly extensive. Maybe there is still room for attacks, but difficult. Pentesters are always welcomed. BTW, man-in-the-middle attack to the entire verification process is possible, but it only has theoretical interests, as the attacker has to stay in the middle between you and your screen. 3. Another general issue is the security of the TOTP seed, like, if your Google Authenticator is hacked. The problem is somehow mitigated by using a Nitrokey/Librem Key, but the TOTP code is still running on a generic STM32F1 MCU, not the OpenPGP Card. STM32F1 is known for its tamper-nonresistance. But because of NDAs, there is currently no good alternative choices though. But still, just like TPM, I think it greatly improves the current situation so far, let's use it. It still has problems, and in the future we may do better. 4. Automation. Librem Key automates the challenge-response, unlike the original Heads, which prints the code on the screen. In the original Heads, if Heads itself is tampered, it will noticed by the user for incorrect/no code. But with automation, perhaps the attacker has a way to trick the users now? Need to check this. > and even then i'm an amateur at cryptography stuff Me too. I'm also working on a similar security token in my spare time. Hopefully, before the New Year, I can submit a Show HN. You may find it's interesting to read. Finally, all of my descriptions are based on my first-hand impressions, not necessarily facts, and totally unverified. Make sure to check the primary sources!
In Introducing the Librem Key

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.