Lennart Poettering, Christian Brauner founded a new company

Most banks already do that. The secure, locked down terminals are called ATMs and they are generally placed at assorted convenient locations in most cities.

If the bank can't be bothered to either implement support for U2F or else clearly articulate why U2F isn't sufficient then they don't have a valid position. Anything else they say on the matter should be disregarded.

Citation needed. The fact that the infosec industry just keeps growing YoY kinda suggests that there are in fact issues that are more expensive than paying the security companies.

https://youtu.be/GZadCj8O1-0

These guys pathologically have had a chip on their shoulder since Napster.

By that logic, we should just turn off the internet. Too much potential for evil there.

More seriously, the argument being presented seems to just be "attestation tech has been used for evil in the past, therefore all attestation tech is bad," which is obviously an unsound argument. A sound argument would have to show that attestation tech is _inherently_ bad, and I've already provided examples that I think effectively counter that. I can provide more if needed.

I get that we want to prevent attestation tech from being used for evil, but that's a regulatory problem, not a technical one. You make this point by framing the evil parties as "corporate and government interests."

Don't get me wrong, I am fully against anything that limits the freedoms of the person that owns the device. I just don't see how any of this is a valid argument that Amutable's mission is bad/immoral/invalid.

Or maybe another argument that's perhaps more aligned with the FOSS ideology: if I want e2e attestation of the software stack on my own devices, isn't this a good thing for me?

Amutability is a huge security feature, with tons of real world applications for good.

The fact that mega corps can abuse consumers is a separate issue. We should solve that with regulation. Don't forsake all the good that this tech can do just because Asus or Google want to infringe on your software freedoms. Frankly, these mega corps are going to infringe on your rights regardlessly, whether or not Amutable exists as a business.

Don't throw the baby out with the bath water.

https://educatedguesswork.org/posts/private-access-tokens/

It would be sufficient to be able to freely choose who you trust as proxy for your attestations *and* the ability to modify that choice at any point later (i.e. there should be some interoperability). That can be your Google/Apple/Samsung ecosystem, your local government, a company operating in whatever jurisdiction you are comfortable with, etc.

There's not really an equivalent here for a computer owned by an individual because it's totally normal for someone to sell or dispose of a computer, and no one expects someone to be responsible for who else might get their hands on it at that point. If you prove a criminal owns a computer that I owned before, then what? Prosecution for failing to protect my computer from thieves, or for reselling it, or gifting it to a neighbor or family friend? Shifting the trust doesn't matter if what gets exposed isn't actually damaging on any way, and that's what the parent comment is asking about.

The first two examples you give seem to be about an unscrupulous government punishing someone for owning a computer that they consider tainted, but it honestly doesn't seem that believable that a government who would do that would require a burden of proof so high as to require cryptographic attestation to decide on something like that. I don't have a rebuttal for "an organization trying to avoid cross-tenant linkage" though because I'm not sure I even understand what it means: an example would probably be helpful.

Whereas the state of the system as a whole immediately after it boots can be attested with secure boot and a TPM sealed secret. No manufacturer keys involved (at least AFAIK).

I'm not actually clear which this is. Are they doing something special for runtime integrity? How are you even supposed to confirm that a system hasn't been compromised? I thought the only realistic way to have any confidence was to reboot it.

Open source operating systems are not a zero sum game. Yes there is a certain gravitational pull from all the work contributed by the big companies. If you aren't contributing "for-hire", then you choose what you want to work on, and what you want to use.

Thanks, this may be the key takeaway from this discussion for me

It's definitely pretty opinionated, and I frequently have to explain to people why "After=" doesn't mean "Wants=", but the result is way more robust than any alternative I'm familiar with.

If you're on a system so constrained that running systemd is a burden, you are probably already using something like buildroot/yocto and have a high degree of control about what init system you use.

Centralized trust Hardware attestation run by third parties creates a single point of trust (and failure). If one vendor controls what’s “trusted,” Linux loses one of its core properties: decentralization. This is a fundamental shift in the threat model.

Misaligned incentives These companies don’t just care about security. They have financial, legal, and political incentives. Over time, that usually means monetization, compliance pressure, and policy enforcement creeping into what started as a “security feature.”

Black boxes Most attestation systems are opaque. Users can’t easily audit what’s being measured, what data is emitted, or how decisions are made. This runs counter to the open, inspectable nature of Linux security today.

Expanded attack surface Adding external hardware, firmware, and vendor services increases complexity and creates new supply-chain and implementation risks. If the attestation authority is compromised, the blast radius is massive.

Loss of user control Once attestation becomes required (or “strongly encouraged”), users lose the ability to fully control their own systems. Custom kernels, experimental builds, or unconventional setups risk being treated as “untrusted” by default.

Vendor lock-in Proprietary attestation stacks make switching vendors difficult. If a company disappears, changes terms, or decides your setup is unsupported, you’re stuck. Fragmentation across vendors also becomes likely.

Privacy and tracking Remote attestation often involves sending unique or semi-unique device signals to external services. Even if not intended for tracking, the capability is there—and history shows it eventually gets used.

Potential for abuse Attestation enables blacklisting. Whether for business, legal, or political reasons, third parties gain the power to decide what software or hardware is acceptable. That’s a dangerous lever to hand over.

Harder incident response If something goes wrong inside a proprietary attestation system, users and distro maintainers may have little visibility or ability to respond independently.

Of course you can already do the above with secure boot coupled with a CPU that implements an fTPM. So I can't speak to the value of this project specifically, only build and boot integrity in general. For example I have no idea what they mean by the bullet "runtime integrity".

https://doc.qubes-os.org/en/latest/user/security-in-qubes/an... For laptops, it helps make tampering obvious. (a different attestation scheme with smaller scope however)

This might not be useful to you personally, however.

A lot of the concerns in this thread center on TPMs, but TPMs are really more akin to very limited HSMs that are actually under the user's control (I gave a longer explanation in a sibling comment but TPMs fundamentally trust the data given to them when doing PCR extensions -- the way that consumer hardware is fundamentally built and the way TPMs are deployed is not useful for physical "attacks" by the device owner).

Yes, you can imagine DRM schemes that make use of them but you can also imagine equally bad DRM schemes that do not use them. DRM schemes have been deployed for decades (including "lovely" examples like the Sony rootkit from the 2000s[1], and all of the stuff going on even today with South Korean banks[2]). I think using TPMs (and other security measures) for something useful to users is a good thing -- the same goes for cryptography (which is also used for DRM but I posit most people wouldn't argue that we should eschew all cryptography because of the existence of DRM).

[1]: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... [2]: https://palant.info/2023/01/02/south-koreas-online-security-...

A rational and intelligent engineer cannot possibly believe that he'll be able to control what a technology is used for after he creates it, unless his salary depends on him not understanding it.

Argument should be technical.

As an aside, it is a bit amusing to me that an initial announcement about a new company working on Linux systems caused the vast majority of people to discuss the impact on personal computers (and games!) rather than servers. I guess we finally have arrived at the fabled "Year of the Linux Desktop" in 2026, though this isn't quite how I expected to find out.

> Attestation of what to whom for which purpose? Which freedom does it allow users to control their keys, how does it square with remote attestation and the wishes of enterprise users?

We do have answers for these questions, and a lot of the necessary components exist already (lots of FOSS people have been working on problems in this space for a while). The problem is that there is still the missing ~20% (not an actual estimate) we are building now, and the whole story doesn't make sense without it. I don't like it when people announce vapourware, so I'm really just trying to not contribute to that problem by describing a system that is not yet fully built, though I do understand that it comes off as being evasive. It will be much easier to discuss all of this once we start releasing things, and I think that very theoretical technical discussions can often be quite unproductive.

In general, I will say that there a lot of unfortunate misunderstandings about TPMs that lead people to assume their only use is as a mechanism for restricting users. This is really not the case, TPMs by themselves are actually more akin to very limited HSMs with a handful of features that can (cooperatively with firmware and operating systems) be used to attest to some aspects of the system state. They are also fundamentally under the users' control, completely unlike the PKI scheme used by Secure Boot and similar systems. In fact, TPMs are really not a useful mechanism for protecting against someone with physical access to the machine -- they have to trust that the hashes they are given to extend into PCRs are legitimate and on most systems the data is even provided over an insecure data line. This is why the security of locked down systems like Xbox One[1] don't really depend on them directly and don't use them at all in the way that they are used on consumer hardware. They are only really useful at protecting against third-party software-based attacks, which is something users actually want!

All of the comments about DRM obviously come from very legitimate concerns about user freedoms, but my views on this are a little too long to fit in a HN comment -- in short, I think that technological measures cannot fix a social problem and the history of DRM schemes shows that the absence of technological measures cannot prevent a social problem from forming either. It's also not as if TPMs haven't been around for decades at this point.

[1]: https://www.youtube.com/watch?v=U7VwtOrwceo

This is basically true today with Secure Boot on modern hardware (at least in the default configuration -- Microsoft's soft-power policies for device manufacturers actually requires that you can change this on modern machines). This is bad, but it is bad because platform vendors decide which default keys are trusted for secure boot by default and there is no clean automated mechanism to enroll your own keys programmatically (at least, without depending on the Microsoft key -- shim does let you do this programmatically with the MOK).

The set of default keys ended up being only Microsoft (some argue this is because of direct pressure from Microsoft, but this would've happened for almost all hardware regardless and is a far more complicated story), but in order to permit people to run other operating systems on modern machines Microsoft signed up to being a CA for every EFI binary in the universe. Red Hat then controls which distro keys are trusted by the shim binary Microsoft signs[1].

This system ended up centralised because the platform vendor (not the device owner) fundamentally controls the default trusted key set and is what caused the whole nightmare of the Microsoft Secure Boot keys and rh-boot signing of shim. Getting into the business of being a CA for every binary in the world is a very bad idea, even if you are purely selfish and don't care about user freedoms (and it even makes Secure Boot less useful of a protection mechanism because it means that machines where users only want to trust Microsoft also necessarily trust Linux and every other EFI binary they sign -- there is no user-controlled segmentation of trust, which is the classic CA/PKI problem). I don't personally know how the Secure Boot / UEFI people at Microsoft feel about this, but I wouldn't be surprised if they also dislike the situation we are all in today.

Basically none of these issues actually apply to TPMs, which are more akin to limited HSMs where the keys and policies are all fundamentally user-controlled in a programmatic way. It also doesn't apply to what we are building either, but we need to finish building it before I can prove that to you.

[1]: https://github.com/rhboot/shim-review

The attestation portion of those systems is happening on locked down devices, and if you gain ownership of the devices they no longer attest themselves.

This is the curse of the duopoly of iOS and Android.

BankID in Sweden will only run with one of these devices, they used to offer a card system but getting one seems to be impossible these days. So you're really stuck with a mobile device as your primary means of identification for banking and such.

There's a reason that general purpose computers are locked to 720p on Netflix and Disney+; yet AppleTV's are not.

Finances, just pay everything by cheque or physical pennies. Fight back. Starve the tyrants to death where you can, force the tyrants to incur additional costs and inefficiencies where you can't.

Chaining trust from POST to login feels like trying to make a theoretically perfect diamond and titanium bicycle that never wears down or falls apart when all I need is an automated system to tell me when to replace a part that’s about to fail.

Reminds me of my old Chromebook Pixel I wiped chromeos from. Every time it booted I had to press Ctrl-L (iirc) to continue the boot, any other keypress would reenable secure boot and the only way I knew to recover from that was to reinstall chromeos, which would wipe my linux partition and my files with it. Needless to say, that computer taught me good backup discipline...

Yes that's the case - my argument is that Linux currently doesn't have anything standardized to do that.

Your best bet for now is to use a read-only dm-verity-protected volume as the root partition, encode its hash in the initrd, combine kernel + initrd into a UKI and sign that.

I would welcome a standardized approach.

Have a look at Ubuntu Core 24 and later. Though it's not exactly a desktop system, but rathe oriented towards embedded/appliances. Recent Ubuntu desktop (from 25.04 IIRC) started getting the same mechanism gradually integrated in each release. Upcoming Ubuntu 26.04 is expected to support TPM backed FDE. Worth a try if you can set up a VM with a software TPM.

Keep in mind though, there's been plenty of issues with various EFI firmwares, especially on the appliances side. EFI specs are apparently treated as guidelines rather than actual specification by whoever ends up implementing the firmware.

You don't need to load a driver; you can just replace a binary that's going to be executed as root as part of system boot. This is something a hypothetical code signature verification would detect and prevent.

Failing kernel-level code signature enforcement, the next best step is to have a dm-verity volume as your root partition, with the dm-verity hashes in the initrd within the UKI, and that UKI being signed with secure boot.

This would theoretically allow you to recover from even root-level compromise by just rebooting the machine (assuming the secure boot signing keys weren't on said machine itself).

This is not what attestation is even seeking to solve.

The oppressive part of this scheme is that Google's integrity check only passes for _their_ keys, which form a chain of trust through the TEE/TPM, through the bootloader and finally through the system image. Crucially, the only part banks should care about should just be the TEE and some secure storage, but Google provides an easy attestation scheme only for the entire hardware/software environment and not just the secure hardware bit that already lives in your phone and can't be phished.

It would be freaking cool if someone could turn your TPM into a Yubikey and have it be useful for you and your bank without having to verify the entire system firmware, bootloader and operating system.

The Free Software movement was successful enough that by 1997 it was garnering a lot of international community support and manpower. Eric S. Raymond published CatB in response to these successes, partly with a goal of "celebrating its successes" — sendmail, gcc, perl, and Linux were all popular projects with a huge number of collaborators by this point — and partly with a goal of reframing the Free Software movement such that it effectively neuters the political basis (i.e. the four freedoms, etc.) in a company-friendly way. It's very easy to note when reading the book, how it consistently celebrates the successes of Free Software in a company friendly way, deliberately to make it appealing to companies. Often being very explicit about its goals, e.g. "Don't give your workers good bonuses, because research shows that the better a ''hacker'' the less they care about money!".

A year later, internal memos from Microsoft leaked that showed that management were indeed scared shitless about Linux, a movement that they could neither completely Embrace, Extend, and Extinguish, nor practice Fear, Uncertainty, and Doubt on, because the community that built it were too strong, and too dedicated. Management foresaw that it was only a matter until Linux was a very strong competitor — even if that's taken 20 years, they were decently accurate in their fears, and, to be honest, part of why it's taken 30 years for Linux to catch up are deliberate actions by Microsoft wrt. introducing and adopting technologies that would stymie the Free Software movement from being able to adapt.

Maybe you want to reread through this thread.

> Eventually you will not be able to block ads.

That's so far down the slippery slope and with so many other things that need to go wrong that I'm not worried and I'm willing to be the one to get "told you so" if it happens.

Yes, system data should be locked to the system with a TPM. That way your system can refuse to boot if it's been modified to steal your user secrets.

About ten years ago I took a three day cross-country Amtrak trip where I wanted to work on some data analysis that used mysql for its backend. It was a great venue for that sort of work because the lack of train-internet was wonderful to keep me focused. The data I was working with was about 20GB of parking ticket data. The data took a while to process over SQL which gave me the chance to check out the world unfolding outside of the train.

At some point, mysql (well, mariadb) got into a weird state after an unclean shutdown that put itself into recovery mode where upon startup it had to do some disk-intensive cleanup. Thing is -- systemd has a default setting (that's not readily documented, nor sufficiently described in its logs when the behavior happens) that halts the service startup after 30 seconds to try again. On loop.

My troubleshooting attempts were unsuccessful. And since I deleted the original csv files to save disk space, I wasn't able to even poke at the CSV files through python or whatnot.

So instead of doing the analysis I wanted to do on the train, I had to wait until I got to the end of the line to fix it. Sure enough, it was some default 30s timeout that's not explicitly mentioned nor commented out like many services do.

So, saying that things are "much better in every way" really falls on deaf ears and is reminiscent of the systemd devs' dismissive/arrogant behavior that many folk are frustrated about.

How can I cancel a systemd startup task that blocks the login prompt? / how is forcing me to wait for dhcp on a network interface that isn't even plugged in a better experience?

Also trying to use systemd with podman is frustrating as hell. You just cannot run a system service using podman as a non-root user and have it work correctly.

System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted.

Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope --property=Delegate=yes <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable.

At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back.

There are more examples, but I'm tired of re-living them and don't really want to write a book. I hope these few are enough to convey my point:

Systemd has been a net negative in my experience. It has made my life markedly worse, without bringing anything I needed. Based on conversations, comments, and bug reports I've seen over the years, I get the impression that many others have had a similar experience, but don't bother speaking up about it any more, because they're tired of being dismissed, ignored, or shouted down, just as I am.

I would welcome a reliable, minimal, non-invasive, dependency-based init. Systemd is not it.

You realize that quite a few senior and experienced developers and devops engineers do not share this view, right?

Somebody will use it and eventually force it if it exists and I don't think gaming especially those requiring anti-cheat is worth that risk.

If that means linux will not be able to overtake window's market share, that's ok. At-least the year of the linux memes will still be funny.

It will.

Then just a bit later no movies for you unless you are running a blessed distro. Then Chrome will start reporting to websites that you are this weird guy with a dangerous unlocked distro, so no banking for you. Maybe no government services as well because obviously you are a hacker. Why would you run an unlocked linux if you were not?

the guys that copy your bitlocker keys in the clear

(London. On some of my relatives.)

Not you. This technology is not being built for you.

But we will never enforce using any of these features in systemd itself. It will always be up to the distro to enable and configure the system to become an immutable monolith. And I certainly don't think distributions like Fedora or Debian will ever go in that direction.

We don't really have any control over what Microsoft decides to do with Secure Boot. If they decide at one point to make Secure Boot reject any Linux distribution and hardware vendors prevent enrolling user owned keys, we're in just as much trouble as everyone else running Linux will be.

I doubt that will actually happen in practice though.

But I'm losing hope with those.

Theoretically, nothing. But it's worth pointing out that so far they have actually done the opposite. They currently mandate that hardware vendors must allow you to enroll your own keys. There was a somewhat questionable move recently where they introduced a 'more secure by default' branding in which the 3rd party CA (used e.g. go sign shim for Linux) is disabled by default, but again, they mandated there must be an easy toggle to enable it. I don't begrudge them to much for it, because there have been multiple instances of SB bypass via 3rd party signed binaries.

All of this is to say: this is not a scenario I'm worried about today. Of course this may change down the line.

Why are you buying hardware that Microsoft controls if you're concerned about this?

As per the announcement, we’ll be building a favorite color over the next months and sharing more information as it rolls out.

Yeah I know what analogies are.

Why does my bank need to know whether the machine in my hands that is accessing their internet APIs was attested by some uninvolved third party or not?

You know we used to hand people pieces of paper with letters and numbers on them to do payments right? For some reason, calling up my bank on the phone never required complicated security arrangements.

TD Bank never needed to come inspect my phone lines to ensure nobody was listening in.

Instead of securing their systems and working on making it harder to have your accounts taken over (which by the way is a fruitful avenue of computer security with plenty of low hanging fruit) and punishing me for their failures, they want to be able to coerce me to only run certain software on my equipment to receive banking services.

This wasn't necessary for banking for literally thousands of years.

Why now? What justification is there?

A third party attesting my device can only be used to compel me to only use certain devices from certain third parties. The bank is not at all going to care whether I attest to it or not, they are going to care that Google or Microsoft will attest my device.

And for what? To what end? To prevent what alleged harm?

In what specific way does an attested device state make interacting with a publicly facing interface more secure?

It WILL be used to prevent you from being able to run certain code that benefits you at corporation's expense, like ad blockers.

Linux is supposed to be an open community. Who even asked for this?

While the bank use case makes a compelling argument, device attestation won't be used for just banks. It's going to be every god damned thing on the internet. Why? Because why the hell not, it further pushes the costs of doing business of banks/MSPs/email providers/cloud services onto the customer and assigns more of the liabilities.

It will also further the digital divide as there will be zero support for devices that fail attestation at any service requiring it. I used to think that the friction against this technology was overblown, but over the last eighteen months I've come to the conclusion that it is going to be a horrible privacy sucking nightmare wrapped in the gold foil of security.

I've been involved in tech a long, long time. The first thing I'm going to do when I retire is start chucking devices. I'm checking-out, none of this is proving to be worth the financial and privacy costs.

If there is real effective market (which is not in any country on Earth, especially for banks), you could say: vote with you money, choose bank which suits you. But it is impossible even with bakery, less with banks on market which is strictly regulated (in part as result of lobbying by established institutions, to protect themselves!).

So, on one hand, I must use banks (I cannot pay for many things in cash, here, where I live most of bars and many shops doesn't accept cash, for example, and it is result of government politics and regulations), and on other hand banks is not seen as essential as access to air and water, they could dictate any terms they want.

I see this situation completely screwed.

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.

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.

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.

[1] https://ubuntu.com/core