Posted by hornedhob 1/27/2026
A reliably attestable system has to nail the entire boot chain: BIOS/firmware, bootloader, kernel/initramfs pairs, the `init` process, and the system configuration. Flip a single bit anywhere along the process, and your equipment is now a brick.
Getting all of this right requires deep system knowledge, plus a lot of hair-pulling adjustment, assuming if you still have hair left.
I think this part of Linux has been underrated. TPM is a powerful platform that is universally available, and Linux is the perfect OS to fully utilize it. The need for trust in digital realm will only increase. Who knows, it may even integrate with cryptocurrency or even social platforms. I really wish them a good luck.
"Those who give up freedom for security deserve neither."
avoiding backdoors as a private person you always can only solve with having the hardware at your place, because hardware ALWAYS can have backdoors, because hardware vendors do not fix their shit.
From my point of view it ONLY gives control and possibilities to large organizations like governments and companies. which in turn use it to control citizens
So, some of the people doing "typical HN rage-posting about DRM" are also absolutely right.
The capabilities locking down macOS and iOS and related hardware also can be used for good, but they are not used for that.
What do you mean by this?
Is the concern that systemd is suddenly going to require that users enable some kind of attestation functionality? That making attestation possible or easier is going to cause third parties to start requiring it for client machines running Linux? This doesn't even really seem to be a goal; there's not really money to be made there.
As far as I can tell the sales pitch here is literally "we make it so you can assure the machines running in your datacenter are doing what they say they are," which seems pretty nice to me, and the perversions of this to erode user rights are either just as likely as they ever were or incredibly strange edge cases.
So, every PC sold to consumers is sanctioned by Microsoft. This list contains Secure Boot and TPM based requirements, too.
If Microsoft decides to eliminate enrollment of user keys and Secure Boot toggle, they can revoke current signing keys for "shims" and force Linux distributions to go full immutable to "sign" their bootloaders so they can boot. As said above, it's not something Amutable can control, but enable by proxy and by accident.
Look, I work in a datacenter, with a sizeable fleet. Being able to verify that fleet is desirable for some kinds of operations, I understand that. On the other hand, like every double edged sword, this can cut in both ways.
I just want to highlight that, that's all.
Now we have immutable distributions (SuSE, Fedora, NixOS). We have the infrastructure for attestation (systemd's UKI, image based boot, and other immutability features), TPMs and controversially uutils (Which is MIT licensed and has the stated goal to replace all GNU userspace).
You can build an immutable and adversarial userspace where you don't have to share the source, and require every boot and application call to attest. The theoretical thickness of the wall is both much greater and this theoretical state is much easier to achieve.
20 years ago the only barrier was booting. After that everything was free. Now it's possible to boot into a prison where your every ls and cd command can be attested.
Oh, Rust is memory safe. Good luck finding holes.
What? As just one example, dm-verity was merged into the mainline kernel 13 years ago. I built immutable, verified Linux systems at least ten years ago, and it was considered old hat by the time I got there.
> The best you could do was, TiVoization, but that would be too obvious and won't fly.
What does this even mean? "TiVoization" is the slang for "you get a device that runs Linux, you get the GPL sources, but you can't flash your own image on the device because you don't own the keys." This is the exact same problem then as it was now and just as "obvious?"
I understand the fears that come from client attestation (certainly, the way it has been used on Android has been majorly detrimental to non-Google ROMs), but, to the Android point, the groundwork has always been there.
I'd be very annoyed if someone showed up and said "we're making a Linux-based browser attestation system that your bank is going to partner on," but nobody has even gone this direction on Windows yet.
> Oh, Rust is memory safe. Good luck finding holes.
I break secure boot systems for a living and I'd say _maybe_ half of the bugs I find relate to memory safety in a way Rust would fix. A lot of systems already use tools which provide very similar safety guarantees to Rust for single threaded code. Systems are definitely getting more secure and I do worry about impenetrable fortresses appearing in the near future, but making this argument kind of undermines credibility in this space IMO.
I do think this approach might get used for client attestation in gaming, which I actually don’t mind; renting/non-owning a client that lets me play against non cheaters is a pretty good gaming outcome, and needing a secure configuration to run games seems like a fine trade for me (vs for example needing a secure desktop configuration to access my bank, which would be irksome).
There is: corporate will fund this project and enforce its usage for their users not for the sake of the users and not for the sake of doing any good.
What it will be used for is to bring you a walled garden into Linux and then slowly incentivize all software vendors to only support that variety of Linux.
LP has a vast, vast experience in locking down users' freedom and locking down Linux.
I'd really love to see this scenario actually explained. The only place I could really see client-side desktop Linux remote attestation gaining any foothold is to satisfy anti-cheat for gaming, which might actually be a win in many ways.
> What it will be used for is to bring you a walled garden into Linux and then slowly incentivize all software vendors to only support that variety of Linux.
What walled garden? Where is the wall? Who owns the garden? What is the actual concrete scenario here?
> LP has a vast, vast experience in locking down users' freedom and locking down Linux.
What? You can still use all of the Linuxes you used to use? systemd is open source, open-application, and generally useful?
Like, I guess I could twist my brain into a vision where each Ubuntu release becomes an immutable rootfs.img and everyone installs overlays over the top of that, and maybe there's a way to attest that you left the integrity protection on, but I don't really see where this goes past that. There's no incentive to keep you from turning the integrity protection off (and no means to do so on PC hardware), and the issues in Android-land with "typical" vendors wanting attestation to interact with you are going to have to come to MacOS and Windows years before they'll look at Linux.
It will be, no doubt. As soon as it is successfully tested and deployed for games, it will be used for movies, government services, banks, etc. And before you know you do not have control of your own computer.
> Who owns the garden?
Not you.
> everyone installs overlays over the top of that
Except this breaks cryptography and your computer is denied multiple services. Because you are obviously a hacker, why else would anyone want to compile and run programs.
> turning the integrity protection off (and no means to do so on PC hardware)
It's a flip of a switch, really. Once Microsoft decides you have had enough, the switch is flipped and in a couple of years no new Intel computer will boot your kernel.
I really, really don't think these entities care enough about desktop Linux. I'd be way more worried about some kind of Windows web-based attestation appearing. If that happens I really do think there's a bit of an alarm to sound, because this will make using desktop Linux inconvenient in the way attestation has made using alternate Android ROMs inconvenient.
> Because you are obviously a hacker, why else would anyone want to compile and run programs.
People buy computers to run programs, it doesn't behoove anyone to prevent this. These things are driven by economics, not some weird arbitrary drive towards evil. Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
> Once Microsoft decides you have had enough, the switch is flipped and in a couple of years no new Intel computer will boot your kernel.
Why does everyone land on this complete non sequitur? It's not the flip of a switch, that's not how UEFI Secure Boot works to start with and even then, UEFI Secure Boot is not the root of trust on x86.
This was indeed the big "Free Software" vs UEFI "Secure" Boot conspiracy theory 20+ years ago, but it didn't make sense then, doesn't make sense now, and sure enough, hasn't come to pass. First off, Microsoft aren't Intel, who own the root of trust on Intel CPUs. Second off, again, there's no incentive to do this. CPUs are a competitive market and people buy CPUs to run code. There is no reason for Intel to suddenly decide to exclusively enforce firmware verification in a way that only chained down to one vendor's keys; they're in the business of selling CPUs to people who want to run things. Also, the notion that some CPU vendor will suddenly lock down firmware keys has nothing to do with the article in question or the notion of an immutable or attestable Linux.
Where I live in Europe, Fairphones are becoming fairly popular (as in, I encounter non-tech people using Fairphones). A subset of those users run /e/OS (anti-Google/big tech sentiment is growing pretty strong). This is increasingly becoming a risk for Google, because if /e/OS takes off big time in Europe, it would be easy to support a European app store besides Google Play and F-Droid (which the /e/OS App Lounge already support), leading to a loss of 30% on app spending.
Google will abuse their remote attestation implementation to shut out competitors. If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
Google actually "gave" customers the choice here, although I agree with you that it's crappy and there was almost surely some monopolistic intent -
There _is_ a standard implementation, the Hardware Attestation API. Unfortunately it is annoying to use in a practical way; it requires a fair amount of PKI-wrangling (although there's a Google library for it) and more importantly to allow non-Google trust chains but still enforce boot security, app developers need all of the verifiedBootKey hashes for the non-Google trust chains they want to trust. This makes sense, but unfortunately becomes a maintenance problem and turns app developers off of this.
So, app developers choose the Play Integrity API instead because it's easy, even though they get the side effect that they verify that the device is a licensed Google Play device rather than just a "clean" Android device.
All this is to say that if something like /e/OS were to actually take off, app developers could upgrade their apps to support attestation with the Hardware Attestation API with some extra effort - Google aren't really preventing them and the feature is there.
Anyway, going all the way back to the original story again, I still can't buy into the hand-wringing. A verified, attestable Linux on the server (or for stuff like forward deployed devices) seems quite cool and useful to me, and while I respect the issues with client attestation and the negative effect it can have on hardware ownership, I both don't see it as a practical outcome from this company and don't see it as a practical threat on the desktop at this time.
and each time the doors have been blasted wide off by huge security vulnerabilities
the attack surface is simply too large when people can execute their own code nearby
You will get 10000 zero days before you get a single direct attack at hardware
1. How will the company make money? (You have probably been asked that a million times :).)
2. Similar to the sibling: what are the first bits that you are going to work on.
At any rate, super cool and very nice that you are based in EU/Germany/Berlin!
2. Given the team, it should be quite obvious there will be a Linux-based OS involved.
Our aims are global but we certainly look forward to playing an important role in the European tech landscape.
I take it that you are not at this stage able to provide details of the nature of the path to revenue. On what kind of timescale do you envisage being able to disclose your revenue stream/subscribers/investors?
As I understand it, the main customers for this sort of thing are companies making Tivo-style products - where they want to use Linux in their product, but they want to lock it down so it can't be modified by the device owner.
This can be pretty profitable; once your customers have rolled out a fleet of hardware locked down to only run kernels you've signed.
That is why Ubuntu Core (and similar) exist. More secure, better update strategy, lower net cost. I don't agree with the licensing or pricing model, but there are perfectly good technical reasons to use it.
I have no more information about your product that you have shared but I'm already scared and extremely pessimistic given the team and the ambition.
A "robust path to revenue" plus a Linux-based OS and a strong emphasis on EU / German positioning immediately triggers some concern. We've seen this pattern before: wrap a commercially motivated control layer in the language of sovereignty, security, or European tech independence, and hope that policymakers, enterprises, and users don't look too closely at the tradeoffs.
Europe absolutely needs stronger participation in foundational tech, but that shouldn't mean recreating the same centralized trust and control models that already failed elsewhere, just with an EU flag on top. 'European sovereignty' is not inherently better if it still results in third-party gatekeepers deciding what hardware, kernels, or systems are "trusted."
Given Europe's history with regulation-heavy, vendor-driven solutions, it's fair to ask:
Who ultimately controls the trust roots?
Who decides policy when commercial or political pressure appears?
What happens when user interests diverge from business or state interests?
Linux succeeded precisely because it avoided these dynamics. Attestation mechanisms that are tightly coupled to revenue models and geopolitical branding risk undermining that success, regardless of whether the company is based in Silicon Valley or Berlin.
Hopefully this is genuinely about user-verifiable security and not another marketing-driven attempt to position control as sovereignty. Healthy skepticism seems warranted until the governance and trust model are made very explicit.