HN Reader

Hi, Chris here, CEO @ Amutable. We are very excited about this. Happy to answer questions.

Please don't bring attestation to common Linux distributions. This technology, by essence, moves trust to a third party distinct of the user. I don't see how it can be useful in any way to end users like most of us here. Its use by corporations has already caused too much damage and exclusion in the mobile landscape, and I don't want folks like us becoming pariahs in our own world, just because we want machines we bought to be ours...

Remote attestation only works because your CPU's secure enclave has a private key burned-in (fused) into it at the factory. It is then provisioned with a digital certificate for its public key by the manufacturer.

Every time you perform an attestation the public key (and certificate) is divulged which makes it a unique identifier, and one that can be traced to the point of sale - and when buying a used device, a point of resale as the new owner can be linked to the old one.

They make an effort to increase privacy by using intermediaries to convert the identifier to an ephemeral one, and use the ephemeral identifier as the attestation key.

This does not change the fact that if the party you are attesting to gets together with the intermediary they will unmask you. If they log the attestations and the EK->AIK conversions, the database can be used to unmask you in the future.

Also note that nothing can prevent you from forging attestations if you source a private-public key pair and a valid certificate, either by extracting them from a compromised device or with help from an insider at the factory. DRM systems tend to be separate from the remote attestation ones but the principles are virtually identical. Some pirate content producers do their deeds with compromised DRM private keys.

Well I was wondering when the war on general computing and computer ownership would be carried into the heart of the open source ecosystems.

Sure, there are sensible things that could be done with this. But given the background of the people involved, the fact that this is yet another clear profit-first gathering makes me incredibly pessimistic.

This pessimism is made worse by reading the answers of the founders here in this thread: typical corporate talk. And most importantly: preventing the very real dangers involved is clearly not a main goal, but is instead brushed off with empty platitudes like "I've been a FOSS guy my entire adult life...." instead of describing or considering actual preventive measures. And even if the claim was true, the founders had a real love for the hacker spirit, there is obviously nothing stopping them from selling to the usual suspects and golden parachute out.

I was really struggling to not make this comment just another snarky, sarcastic comment, but it is exhausting. It is exhausting to see the hatred some have for people just owning their hardware. So sorry, "don't worry, we're your friends" just doesn't cut it to come at this with a positive attitude.

The benefits are few, the potential to do a lot of harm is large. And the people involved clearly have the network and connections to make this an instrument of user-hostility.

This seems like the kind of technology that could make the problem described in https://www.gnu.org/philosophy/can-you-trust.en.html a lot worse. Do you have any plans for making sure it doesn't get used for that?

My only experience with Linux secure boot so far.... I wasn't even aware that it was secure booted. And I needed to run something (I think it was the Displaylink driver) that needs to jam itself into the kernel. And the convoluted process to do it failed (it's packaged for Ubuntu but I was installing it on a slightly outdated Fedora system).

What, this part is only needed for secure boot? I'm not sec... oh. So go back to the UEFI settings, turn secure boot off, problem solved. I usually also turn off SELinux right after install.

So I'm an old greybeard who likes to have full control. Less secure. But at least I get the choice. Hopefully I continue to do so. The notion of not being able to access online banking services or other things that require account login, without running on a "fully attested" system does worry me.

Remote attestation is another technology that is not inherently restrictive of software freedom. But here are some examples of technologies that have already restricted freedom due to oligopoly combined with network effects:

* smartphone device integrity checks (SafetyNet / Play Integrity / Apple DeviceCheck)

* HDMI/HDCP

* streaming DRM (Widevine / FairPlay)

* Secure Boot (vendor-keyed deployments)

* printers w/ signed/chipped cartridges (consumables auth)

* proprietary file formats + network effects (office docs, messaging)

Well, I can see what heinous thing is going to be ruining my day in 5 years.

Attestation, the thing we're going to be spending the next forever trying to get out of phones, now in your kernel.

systemd solved/improved a bunch of things for linux, but now the plan seems to be to replace package management with image based whole dist a/b swaps. and to have signed unified kernel images.

this basically will remove or significantly encumber user control over their system, such that any modification will make you loose your "signed" status and ... boom! goodbye accessing the internet without an id

pottering recently works for Microsoft, they want to turn linux into an appliance just like windows, no longer a general purpose os. the transition is still far from over on windows, but look at android and how the google play services dependency/choke-hold is

im sure ill get many down votes, but despite some hyperbole this is the trajectory

Entities other than me being able to control what runs on the device I physically posses is absolutely not acceptable in any way. Screw your clients, screw you shareholders and screw you.

Exciting!

It sounds like you want to achieve system transparency, but I don't see any clear mention of reproducible builds or transparency logs anywhere.

I have followed systemd's efforts into Secure Boot and TPM use with great interest. It has become increasingly clear that you are heading in a very similar direction to these projects:

- Hal Finney's transparent server

- Keylime

- System Transparency

- Project Oak

- Apple Private Cloud Compute

- Moxie's Confer.to

I still remember Jason introducing me to Lennart at FOSDEM in 2020, and we had a short conversation about System Transparency.

I'd love to meet up at FOSDEM. Email me at fredrik@mullvad.net.

Edit: Here we are six years later, and I'm pretty sure we'll eventually replace a lot of things we built with things that the systemd community has now built. On a related note, I think you should consider using Sigsum as your transparency log. :)

Edit2: For anyone interested, here's a recent lightning talk I did that explains the concept that all project above are striving towards, and likely Amutable as well: https://www.youtube.com/watch?v=Lo0gxBWwwQE

Ah, good old remote attestation. Always works out brilliantly.

I have this fond memory of that Notary in Germany who did a remote attestation of me being with him in the same room, voting on a shareholder resolution.

While I was currently traveling on the other side of the planet.

This great concept that totally will not blow up the planet has been proudly brought to you by Ze Germans.

No matter what your intentions are: It WILL be abused and it WILL blow up. Stop this and do something useful.

[While systemd had been a nightmare for years, these days its actually pretty good, especially if you disable the "oh, and it can ALSO create perfect eggs benedict and make you a virgin again while booting up the system!" part of it. So, no bad feelings here. Also, I am German. Also: Insert list of history books here.]

What is the endgame here? Obviously "heightened security" in some kind of sense, but to what end and what mechanisms? What is the scope of the work? Is this work meant to secure forges and upstream development processes via more rigid identity verification, or package manager and userspace-level runtime restrictions like code signing? Will there be a push to integrate this work into distributions, organizations, or the kernel itself? Is hardware within the scope of this work, and to what degree?

The website itself is rather vague in its stated goals and mechanisms.

Do you plan to sell this technology to laptop makers so their laptops will only run the OS they came with?

I really hope this would be geared towards clients being able to verify the server state or just general server related usecases, instead of trying to replicate SafetyNet-style corporate dystopia on the desktop.

To me this looks bad on so many levels. I hate it immediately.

One good news is that maybe LP will get less involved in systemd.

>Amutable is based out of Berlin, Germany.

Probably obvious from the surnames but this is the first time I've seen a EU company pop up on Hacker News that could be mistaken for a Californian company. Nice to see that ambition.

I understand systemd is controversial, that can be debated endlessly but the executive team and engineering team look very competitive. Will be interesting to see where this goes.

Hello Chris,

I am glad to see these efforts are now under an independent firm rather than being directed by Microsoft.

What is the ownership structure like? Where/who have you received funding from, and what is the plan for ongoing monetization of your work?

Would you ever sell the company to Microsoft, Google, or Amazon?

Thanks.

Lennart will be involved with at least three events at FOSDEM on the coming weekend. The talks seem unrelated at first glance but maybe there will be an opportunity to learn more about his new endeavor.

https://fosdem.org/2026/schedule/speaker/lennart_poettering/

"We are building cryptographically verifiable integrity into Linux systems. Every system starts in a verified state and stays trusted over time."

What does this mean? Why would anyone want this? Can you explain this to me like I'm five years old?

This feels like something that's being created for a Microsoft edition of Linux.

Remote attestation requires a great deal of trust... I know this comment is likely to be down-voted, but I can't think of a Lennart Poettering project that didn't try to extend, centralize, and conglomerate Linux with disastrous results in the short term; and less innovation, flexibility, and functionality in the long term. Trading the strength of Unix systems for goal of making them more "Microsoft" like.

Remote attestation requires a great deal of trust, and I simply don't have it when it comes to this leadership team.

Good thing, without the power coming from RedHat money, the capacity of ruining the Linux ecosystem will finally be reduced!

How do you plan handle the confused deputy problem?[1]

[1] https://en.wikipedia.org/wiki/Confused_deputy_problem

Everything under the assumption that tampering is a bigger problem then abusive companies controlling your software stack.

Awful. I hope they fall.

I think https://0pointer.net/blog/authenticated-boot-and-disk-encryp... is a much better explanation of the motivation behind this straight from the horse's mouth. It does a really good job of motivating the need for this in a way that explains why you as the end user would desire such features.

Can you share more details at this point about what you are trying to tackle as a first step?

I always wondered how this works in practice for "real time" use cases because we've seen with secure boot + tpm that we can attest that the boot was genuine at some point in the past, what about modifications that can happen after that?

- How different is this from Fedora BlueFin or silverblue?

- it looks like they want to build a ChromeOS without Google.

Frankly this disgusts me. While there are technically user-empowering ways this can be used, by far the most prevalent use will be to lock users/customers out of true ownership of their own devices.

Device attestation fails? No streaming video or audio for you (you obvious pirate!).

Device attestation fails? No online gaming for you (you obvious cheater!).

Device attestation fails? No banking for you (you obvious fraudster!).

Device attestation fails? No internet access for you (you obvious dissident!).

Sure, there are some good uses of this, and those good uses will happen, but this sort of tech will be overwhelmingly used for bad.

The immediate concern seeing this is will the maintainer of systemd use their position to push this on everyone through it like every other extended feature of systemd?

Whatever it is, I hope it doesn't go the usual path of a minimal support, optional support and then being virtually mandatory by means of tight coupling with other subsystems.

Great; how can I short it?

So I imagine Lennart Poettering has left Microsoft.

I'll ask the dumb question sorry!

Who is this for / what problem does it solve?

I guess security? Or maybe reproducability?

fantastic news, congrats on launching! it's a great mission statement a fanstastic ensemble for the job

Is this headed towards becoming a new Linux distribution or hardening existing ones?

So much negativity in this thread. I actually think this could be useful, because tamper-proof computer systems are useful to prevent evil maid attacks. Especially in the age of Pegasus and other spyware, we should also take physical attack vectors into account.

I can relate to people being rather hostile to the idea of boot verification, because this is a process that is really low level and also something that we as computer experts rarely interact with more deeply. The most challenging part of installing a Linux system is always installing the boot loader, potentially setting up an UEFI partition. These are things that I don't do everyday and that I don't have deep knowledge in. And if things go wrong, then it is extra hard to fix things. Secure boot makes it even harder to understand what is going on. There is a general lack of knowledge of what is happening behind the scenes and it is really hard to learn about it. I feel that the people behind this project should really keep XKCD 2501 in mind when talking to their fellow computer experts.

1. Are reproducible builds and transparency logging part of your concept?

2. Are you looking for pilot customers?

Will you always offer an option to end users to disable the system if they so desire?

Are there VCs who participated in funding this or are you self funded?

How long until you have SIL-4 under control and can demonstrate it?

Hmph, AFAIK systemd has been struggling with TPM stuff for a while (much longer than I anticipated). It’s kinda understandable that the founder of systemd is joining this attestation business, because attestation ultimately requires far more than a stable OS platform plus an attestation module.

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.

Just get a Mac, I guess.

Will this do remote attestation ? What hardware platforms will it support? (Intel sgx, AMD sev, AWS nitro?)

So LP is or has left Microsoft ?

>We are building cryptographically verifiable integrity into Linux systems

I wonder what that means ? It could be a good thing, but I tend to think it could be a privacy nightmare depending on who controls the keys.

Amazing, I wish them great success! <3

The photos depict these people as funny hobbits :D. Photographer trolled them big time. Now, the only question left is whether their feet are hairy.

---

Making secure boot 100 times simpler would be a deffo plus.

Looking forward to never using any of this, quite frankly; and hoping it remains optional for the kernel.

If there’s a path to profitability, great for them, and for me too; because it means it won’t be available at no charge.

Are you guys hiring? I can emulate a grim smile and have no problem being diabolical if the pay is decent so maybe I am a good fit? I can also pet goats

I chuckle because their official adress is just 20 minutes from my home / current location.

I wish you great success

Great team, hope you guys all the best!

It might be a good time to rewrite systemd in rust...

How do they plan to make Linux (with MLoCs...) deterministic?

Why not adopt seL4 like everybody else who is not outright delusional[0][1]?

0. https://sel4.systems/Foundation/Membership/

1. https://sel4.systems/use.html

Why on earth would somebody make a company with one of the the most reviled programmers on earth? Everyone knows that everything he touches turns to shit.

All vague hand waving at this point and not much to talk about. We'll have to wait and see what they deliver, how it works and the business model to judge how useful it will be.

No. Esp with LP’s track record in systemd.

See: “it’s just an init system”where it’s now also a resolver, log system, etc.

I can buy good intentions, but this opens up too much possibility for not-so-good-intended consequences. Deliberate or emergent.

Coming from software supply chain, I am excited to see such a cracked team handle this problem and I wish we talked more about this in FOSS land.

What will they be reinventing from scratch for no reason?

What might you call a sort of Dunbar's number that counts not social links, but rather the number of things to which a person must actively refuse consent to?

Hopefully he will leave systemd alone and stop closing bugs he doesn't understand now

Can someone smarter than myself describe immutability versus atomicity in regards to current operating systems on the market?

I see the use case for servers targeted by malicious actors. A penetration test on an hardened system with secure boot and binary verification would be much harder.

For individuals, IMO the risk mostly come from software they want to run (install script or supply chain attack). So if the end user is in control of what gets signed, I don't see much benefit. Unless you force users to use an app store...

Remote attestation only works because your CPU's secure enclave has a private key burned-in (fused) into it at the factory. It is then provisioned with a digital certificate for its public key by the manufacturer.

The first steps look similar to secure boot with TPM.

Some people just can't stop making other's lives more miserable, can they.

Why have the responses to the post from the CEO been moved to their own top-level posts? Also, why are replies disabled for the CEO post?

The typical HN rage-posting about DRM aside, there's no reason that remote attestation can't be used in the opposite direction: to assert that a server is running only the exact code stack it claims to be, avoiding backdoors. This can even be used with fully open-source software, creating an opportunity for OSS cloud-hosted services which can guarantee that the OSS and the build running on the server match. This is a really cool opportunity for privacy advocates if leveraged correctly - the idea could be used to build something like Apple's Private Cloud Compute but even more open.

Trusted computing and remote attestation is like two people who want to have sex requiring clean STD tests first. Either party can refuse and thus no sex will happen. A bank trusting a random rooted smartphone is like having sex with a prostitute with no condom. The anti-attestation position is essentially "I have a right to connect to your service with an unverified system, and refusing me is oppression." Translate that to the STD context and it sounds absurd - "I have a right to have sex with you without testing, and requiring tests violates my bodily autonomy."

You're free to root your phone. You're free to run whatever you want. You're just not entitled to have third parties trust that device with their systems and money. Same as you're free to decline STD testing - you just don't get to then demand unprotected sex from partners who require it.

Really excited to a company investing into immutable and cryptographically verifiable systems. Two questions really:

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!

Disgusting.

this is very interesting... been watching the work around bootc coupling with composefs + dm_verity + signed UKI, I'm wondering if this will build upon that.

I knew they had an authoritarian streak. This is not surprising, and frankly horrifyingly dystopian.

"Those who give up freedom for security deserve neither."

Shall it be backdoorable like systemd-enabled distro nearly had a backdoorable SSH? For non-systemd distro weren't affected.

Why should we trust microsofties to produce something secure and non-backdoored?

And, lastly, why should Linux's security be tied to a private company? Oooh, but it's of course not about security: it's about things like DRM.

I hope Linus doesn't get blinded here: systemd managed to get PID 1 on many distros but they thankfully didn't manage, yet, to control the kernel. I hope this project ain't the final straw to finally meddle into the kernel.

Currently I'm doing:

    Proxmox / systemd-less VMs / containers

But Promox is Debian based and Debian really drank too much of the systemd koolaid.

So my plan is:

    FreeBSD / bhyve hypervisor / systemd-less Linux VMs / containers

And then I'll be, at long last, systemd-free again.

This project is an attack on general-purpose computing.

amutable -k

Terrible idea, I hope go bankrupt.

I can see like a 100 ways this can make computing worse for 99% people and like 1-2 scenarios where it might actually be useful.

Like if the politicians pushing for chat control/on device scanning of data come knocking again and actually go through (they can try infinitely) tech like this will really be "useful". Oops your device cannot produce a valid attestation, no internet for you.

Lennart Poettering. The leading expert in forcing things down your throat. Great.

Hi Chris,

One of the most grating pain points of the early versions of systemd was a general lack of humility, some would say rank arrogance, displayed by the project lead and his orbiters. Today systemd is in a state of "not great, not terrible" but it was (and in some circles still is) notorious for breaking peoples' linux installs, their workflows, and generally just causing a lot of headaches. The systemd project leads responded mostly with Apple-style "you're holding it wrong" sneers.

It's not immediately clear to me what exactly Amutable will be implementing, but it smells a lot like some sort of DRM, and my immediate reaction is that this is something that Big Tech wants but that users don't.

My question is this: Has Lennart's attitude changed, or can linux users expect more of the same paternalism as some new technology is pushed on us whether we like it or not?

First thing that comes to mind is anti cheat software. Would that be something solved if these objectives are achieved?

For all those people saying negative please see all the comments when RedHat was acquired by IBM (2018)

https://news.ycombinator.com/item?id=18321884

- Linux is better now

- Nothing bad

Been wanting this ever since doing it in Fuchsia. Really excited to see added focus and investment in this for the Linux ecosystem.

Everyday the world is becoming more polarized. Technology corporations gain ever more control over people's lives, telling people what they can do on their computers and phones, what they can talk about on social platforms, censoring what they please, wielding the threat of being cutoff from their data, their social circles on a whim. All over the world, in dictatorships and also in democratic countries, governments turn more fascist and more violent. They demonstrate that they can use technology to oppress their population, to hunt dissent and to efficiently spread propaganda.

In that world, authoring technology that enables this even more is either completely mad or evil. To me Linux is not a technological object, it is also a political statement. It is about choice, personal freedom, acceptance of risk. If you build software that actively intends to take this away from me to put it into the hands of economic interests and political actors then you deserve all the hate you can get.

People demonize attestation. They should keep in mind that far from enslaving users, attestation actually enables some interesting, user-beneficial software shapes that wouldn't be possible otherwise. Hear me out.

Imagine you're using a program hosted on some cloud service S. You send packets over the network; gears churn; you get some results back. What are the problems with such a service? You have no idea what S is doing with your data. You incur latency, transmission time, and complexity costs using S remotely. You pay, one way or another, for the infrastructure running S. You can't use S offline.

Now imagine instead of S running on somebody else's computer over a network, you run S on your computer instead. Now, you can interact with S with zero latency, don't have to pay for S's infrastructure, and you can supervise S's interaction with the outside world.

But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.

However --- if S's author could run S on your computer in such a way that he could prove you haven't tampered with S or haven't observed its secrets, he can let you run S on your computer without giving up control over S. Attestation, secure enclaves, and other technologies create ways to distribute software that otherwise wouldn't exist. How many things are in the cloud solely to enforce access control? What if they didn't have to be?

Sure, in this deployment model, just like in the cloud world, you wouldn't be able to run a custom S: but so what? You don't get to run your custom S either way, and this way, relative to cloud deployment, you get better performance and even a little bit more control.

Also, the same thing works in reverse. You get to run your code remotely in a such a way that you can trust its remote execution just as much as you can trust that code executing on your own machine. There are tons of applications for this capability that we're not even imagining because, since the dawn of time, we've equated locality with trust and can now, in principle, decouple the two.

Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.