Back

Lennart Poettering, Christian Brauner founded a new company

208 points6 hoursamutable.com
blixtra6 hours ago

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

egorfine43 minutes ago

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.

awithrow36 minutes ago

If you're going to flame it you might as well point out something concrete you don't like about it.

josephcsible6 hours ago

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?

cyphar5 hours ago

I'm Aleksa, one of the founding engineers. We will share more about this in the coming months but this is not the direction nor intention of what we are working on. The models we have in mind for attestation are very much based on users having full control of their keys. This is not just a matter of user freedom, in practice being able to do this is far more preferable for enterprises with strict security controls.

I've been a FOSS guy my entire adult life, I wouldn't put my name to something that would enable the kinds of issues you describe.

ahartmetz43 minutes ago

So far, that's a slick way to say not really. You are vague where it counts, and surely you have a better idea of the direction than you say.

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?

teiferer2 hours ago

> I've been a FOSS guy my entire adult life, I wouldn't put my name to something that would enable the kinds of issues you describe.

Until you get acquired, receive a golden parachute and use it when realizing that the new direction does not align with your views anymore.

But, granted, if all you do is FOSS then you will anyway have a hard time keeping evil actors from using your tech for evil things. Might as well get some money out of it, if they actually dump money on you.

iamnothere4 hours ago

Thanks, this would be helpful. I will follow on by recommending that you always make it a point to note how user freedom will be preserved, without using obfuscating corpo-speak or assuming that users don’t know what they want, when planning or releasing products. If you can maintain this approach then you should be able to maintain a good working relationship with the community. If you fight the community you will burn a lot of goodwill and will have to spend resources on PR. And there is only so much that PR can do!

Better security is good in theory, as long as the user maintains control and the security is on the user end. The last thing we need is required ID linked attestation for accessing websites or something similar.

LooseMarmoset2 hours ago

that’s great that you’ll let users have their own certificates and all, but the way this will be used is by corporations to lock us out into approved Linux distributions. Linux will be effectively owned by RedHat and Microsoft, the signing authority.

it will be railroaded through in the same way that systemD was railroaded onto us.

dTal5 hours ago

Thanks for the reassurance, the first ray of sunshine in this otherwise rather alarming thread. Your words ring true.

It would be a lot more reassuring if we knew what the business model actually was, or indeed anything else at all about this. I remain somewhat confused as to the purpose of this announcement when no actual information seems to be forthcoming. The negative reactions seen here were quite predictable, given the sensitive topic and the little information we do have.

michaelmrose3 hours ago

This is extremely bad logic. The technology of enforcing trusted software is without inherent value good or ill depending entirely on expected usage. Anything that is substantially open will be used according to the values of its users not according to your values so we ought instead to consider their values not yours.

Suppose you wanted to identify potential agitators by scanning all communication for indications in a fascist state one could require this technology in all trusted environments and require such an environment to bank, connect to an ISP, or use Netflix.

One could even imagine a completely benign usage which only identified actual wrong doing alongside another which profiled based almost entirely on anti regime sentiment or reasonable discontent.

The good users would argue that the only problem with the technology is its misuse but without the underlying technology such misuse is impossible.

One can imagine two entirely different parallel universes one in which a few great powers went the wrong way in part enabled by trusted computing and the pervasive surveillance enabled by the capability of AI to do the massive and boring task of analyzing a massive glut of ordinary behaviour and communication + tech and law to ensure said surveillance is carried out.

Even those not misusing the tech may find themselves worse off in such a world.

Why again should we trust this technology just because you are a good person?

enriquto5 hours ago

half of the founders of this thing come from Microsoft. I suppose this makes the answer to your question obvious.

stackghost5 hours ago

My thoughts exactly. We're probably witnessing the beginning of the end of linux users being able to run their own kernels. Soon:

- your bank won't let you log in from an "insecure" device.

- you won't be able to play videos on an "insecure" device.

- you won't be able to play video games on an "insecure" device.

And so on, and so forth.

dijit4 hours ago

Unfortunately the parent commenter is completely right.

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.

+1
yxhuvud3 hours ago
seba_dos14 hours ago

This is already the world we live in when it comes to the most popular personal computing devices running Linux out there.

blibble4 hours ago

that's a silver lining

the anti-user attestation will at least be full of security holes, and likely won't work at all

sam_lowry_4 hours ago

Dunno about the others but Pottering has proven himself to deliver software against the grain.

+1
dijit4 hours ago
wang_li2 hours ago

I thought he had proven that he leaves before the project is complete and functioning according to all the promises made.

VortexLain45 minutes ago

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.

9NRtKyP45 hours ago

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)

cwillu5 hours ago

It very clearly is restrictive of software freedom. I've never suffered from an evil maid breaking into my house to access my computer, but I've _very_ frequently suffered from corporations trying to prevent me from doing what I wish with my own things. We need to push back on this notion that this sort of thing was _ever_ for the end-user's benefit, because it's not.

avadodin58 minutes ago

To play devil's advocate, I don't think most people would be fine with their car ramming into a military base after an unfriendly firmware update.

However, I agree that the risks to individuals and their freedoms stemming from these technologies outweigh the benefits in most cases.

myaccountonhn3 hours ago

It's interesting there's no remote attestation the other way around, making sure the server is not doing something to your data that you didn't approve of.

minitech2 hours ago

There is. Signal uses it, for example. https://signal.org/blog/building-faster-oram/

For another example, IntegriCloud: https://secure.integricloud.com/

tryauuum2 hours ago

confidential computing?

digiown4 hours ago

I am quite conflicted here. On one hand I understand the need for it (offsite colo servers is the best example). Basic level of evil maid resistance is also a nice to have on personal machines. On the other hand we have all the things you listed.

I personally don't think this product matters all that much for now. These types of tech is not oppressive by itself, only when it is being demanded by an adversary. The ability of the adversary to demand it is a function of how widespread the capability is, and there aren't going to be enough Linux clients for this to start infringing on the rights of the general public just yet.

A bigger concern is all the efforts aimed at imposing integrity checks on platforms like the Web. That will eventually force users to make a choice between being denied essential services and accepting these demands.

I also think AI would substantially curtail the effect of many of these anti-user efforts. For example a bot can be programmed to automate using a secure phone and controlled from a user-controlled device, cheat in games, etc.

yencabulator1 hour ago

> On one hand I understand the need for it (offsite colo servers is the best example).

Great example of proving something to your own organization. Mullvad is probably the most trusted VPN provider and they do this! But this is not a power that should be exposed to regular applications, or we end up with a dystopian future of you are not allowed to use your own computer.

9NRtKyP45 hours ago

The authors clearly don’t intend this to happen but that doesn’t matter. Someone else will do it. Maybe this can be stopped with licensing as we tried to stop the SaaS loophole with GPLv3?

Foxboron4 hours ago

> * Secure Boot (vendor-keyed deployments)

I wish this myth would die at this point.

Secure Boot allows you to enroll your own keys. This is part of the spec, and there are no shipped firmwares that prevents you from going through this process.

LooseMarmoset59 minutes ago

Android lets you put your own signed keys in on certain phones. For now.

The banking apps still won't trust them, though.

To add a quote from Lennart himself:

"The OS configuration and state (i.e. /etc/ and /var/) must be encrypted, and authenticated before they are used. The encryption key should be bound to the TPM device; i.e system data should be locked to a security concept belonging to the system, not the user."

Your system will not belong to you anymore. Just as it is with Android.

digiown4 hours ago

> Secure Boot allows you to enroll your own keys

UEFI secure boot on PCs, yes for the most part. A lot of mobile platforms just never supported this. It's not a myth.

Foxboron4 hours ago

Phones don't implement UEFI.

+1
seba_dos14 hours ago
yjftsjthsd-h3 hours ago

> This is part of the spec, and there are no shipped firmwares that prevents you from going through this process.

Microsoft required that users be able to enroll their own keys on x86. On ARM, they used to mandate that users could not enroll their own keys. That they later changed this does not erase the past. Also, I've anecdotally heard claims of buggy implementations that do in fact prevent users from changing secure boot settings.

2019843 hours ago

What about all those Windows on ARM laptops?

MarkusWandel5 hours ago

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.

Nextgrid4 hours ago

Secure Boot only extends the chain of trust from your firmware down the first UEFI binary it loads.

Currently SB is effectively useless because it will at best authenticate your kernel but the initrd and subsequent userspace (including programs that run as root) are unverified and can be replaced by malicious alternatives.

Secure Boot as it stands right now in the Linux world is effectively an annoyance that’s only there as a shortcut to get distros to boot on systems that trust Microsoft’s keys but otherwise offer no actual security.

It however doesn’t have to be this way, and I welcome efforts to make Linux just as secure as proprietary OSes who actually have full code signature verification all the way down to userspace.

Fischgericht2 hours ago

Yes, "just as secure as proprietary OSes" who due to failed signature verification are no longer able to start notepad.exe.

I think you might want to go re-read the last ~6 months of IT news in regards of "secure proprietary OSes".

okanat44 minutes ago

There is some level of misinformation in your post. Both Windows and Linux check driver signatures. Once you boot Linux in UEFI Secure Boot, you cannot use unsigned drivers because the kernel can detect and activate the lockdown mode. You have to sign all of the drivers within the same PKI of your UEFI key.

blibble2 hours ago

you can merge the initrd + kernel into one signed binary pretty easily with systemd-boot

add luks root, then it's not that bad

ahepp3 hours ago

Isn't it possible to force TPM measurements for stuff like the kernel command line or initramfs hash to match in order to decrypt the rootfs? Or make things simpler with UKIs?

Most of the firmwares I've used lately seem to allow adding custom secureboot keys.

direwolf201 hour ago

Fine as long as it's managed by the user. A good check is who installed the keys. A user–freedom–respecting secureboot must have user–generated keys.

digiown4 hours ago

A basic setup to make use of secure boot is SB+TPM+LUKS. Unfortunately I don't know of any distro that offers this in a particularly robust way.

Code signature verification is an interesting idea, but I'm not sure how it could be achieved. Have distro maintainers sign the code?

shit_game3 hours ago

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.

storystarling3 hours ago

I suspect the endgame is confidential computing for distributed systems. If you are running high value workloads like LLMs in untrusted environments you need to verify integrity. Right now guaranteeing that the compute context hasn't been tampered with is still very hard to orchestrate.

yencabulator58 minutes ago

That endgame has so far been quite unreachable. TEE.fail is the latest in a long sequence of "whoever touches the hardware can still attack you".

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

https://arstechnica.com/security/2025/09/intel-and-amd-trust...

LooseMarmoset55 minutes ago

No, the endgame is that a small handful of entities or a consortium will effectively "own" Linux because they'll be the only "trusted" systems. Welcome to locked-down "Linux".

You'll be free to run your own Linux, but don't expect it to work outside of niche uses.

kfreds5 hours ago

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

davidstrauss5 hours ago

Hi, I'm David, founding product lead.

Our entire team will be at FOSDEM, and we'd be thrilled to meet more of the Mullvad team. Protecting systems like yours is core to us. We want to understand how we put the right roots of trust and observability into your hands.

Edit: I've reached out privately by email for next steps, as you requested.

kfreds4 hours ago

Hi David. Great! I actually wasn't planning on going due to other things, but this is worth re-arranging my schedule a bit. See you later this week. Please email me your contact details.

As I mentioned above, we've followed systemd's development in recent years with great interest, as well as that of some other projects. When I started(*) the System Transparency project it was very much a research project.

Today, almost seven years later, I think there's a great opportunity for us to reduce our maintenance burden by re-architecting on top of systemd, and some other things. That way we can focus on other things. There's still a lot of work to do on standardizing transparency building blocks, the witness ecosystem(**), and building an authentication mechanism for system transparency that weaves it all together.

I'm more than happy to share my notes with you. Best case you build exactly what we want. Then we don't have to do it. :)

*: https://mullvad.net/en/blog/system-transparency-future

**: https://witness-network.org

Phelinofist4 hours ago

I'm super far from an expert on this, but it NEEDS reproducible builds, right? You need to start from a known good, trusted state - otherwise you cannot trust any new system states. You also need it for updates.

kfreds4 hours ago

Well, it comes down to what trust assumptions you're OK with. Reproducible reduces trust in the build environment, but you still need to ensure authenticity of the source somehow. Verified boot, measured boot, repro builds, local/remote attestation, and transparency logging provide different things. Combined they form the possibility of a sort of authentication mechanism between a server and client. However, all of the concepts are useful by themselves.

getcrunk5 hours ago

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

s_dev5 hours ago

>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.

weinzierl5 hours ago

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/

captn3m04 hours ago

Also see http://amutable.com/events which lists a talk at Open Confidential Computing Conference (Berlin, March)

NewJazz3 hours ago

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.

direwolf201 hour ago

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

No matter what the founders say, the answer to this question is always yes.

direwolf206 hours ago

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

hedora4 hours ago

Or, worse, run any unsupported linux as long as it contains systemd, so no *bsd, etc, and also no manufacturer support?

greatgib5 hours ago

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

egypturnash4 hours ago

"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?

direwolf201 hour ago

Your computer will come with a signed operating system. If you modify the operating system, your computer will not boot. If you try to install a different operating system, your computer will not boot.

mikewarot4 hours ago

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

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

fennec-posix1 hour ago

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.

raggi2 hours ago

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

Thaxll6 hours ago

The first steps look similar to secure boot with TPM.

bayindirh6 hours ago

It starts from there, then systemd takes over and carries the flag forward.

See the "features" list from systemd 257/258 [0].

[0]: https://0pointer.net/blog/

icar2 hours ago

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

kfreds5 hours ago

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

2. Are you looking for pilot customers?

esseph5 hours ago

Damn, you are thirsty!

Are these some problems you've personally been dealing with?

kfreds4 hours ago

I just want more trustworthy systems. This particular concept of combining reproducible builds, remote attestation and transparency logs is something I came up with in 2018. My colleagues and I started working on it, took a detour into hardware (tillitis.se) and kind of got stuck on the transparency part (sigsum.org, transparency.dev, witness-network.org).

Then we discovered snapshot.debian.org wasn't feeling well, so that was another (important) detour.

Part of me wish we had focused more on getting System Transparency in its entirety in production at Mullvad. On the other hand I certainly don't regret us creating Tillitis TKey, Sigsum, taking care of Debian Snapshot service, and several other things.

Now, six years later, systemd and other projects have gotten a long way to building several of the things we need for ST. It doesn't make sense to do double work, so I want to seize the moment and make sure we coordinate.

MomsAVoxell3 hours ago

These kinds of problems are very common in certain industries.

devsda5 hours ago

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.

DaanDeMeyer5 hours ago

Daan here, founding engineer and systemd maintainer.

So we try to make every new feature that might be disruptive optional in systemd and opt-in. Of course we don't always succeed and there will always be differences in opinion.

Also, we're a team of people that started in open source and have done open source for most of our careers. We definitely don't intend to change that at all. Keeping systemd a healthy project will certainly always stay important for me.

bayindirh5 hours ago

Hi Daan,

Thanks for the answer. Let me ask you something close with a more blunt angle:

Considering most of the tech is already present and shipping in the current systemd, what prevents our systems to become a immutable monolith like macOS or current Android with the flick of a switch?

Or a more grave scenario: What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle, hence every Linux distribution has to go through Microsoft's blessing to be bootable?

DaanDeMeyer5 hours ago

So adding all of this technology will certainly make it more easy to be used for either good or bad. And it will certainly become possible to build an OS that will be less hackable than your run of the mill Linux distro.

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.

cwillu5 hours ago

I would be _shocked_ if, conditional on your project being successful, this _wasn't_ commonly used to lock down computing abilities commonly taken for granted today. And I think you know this.

jacquesm3 hours ago

> So adding all of this technology will certainly make it more easy to be used for either good or bad.

Then maybe you shouldn't be doing it?

ongy3 hours ago

Hopefully cartel regulation would prevent Microsoft from using their market leader position to force partners to remove all support for competitors.

But I'm losing hope with those.

noosphr5 hours ago

Nothing, but openbsd is amazing and just works. Anyone still using Linux on the desktop in 2026 should switch.

+2
bayindirh5 hours ago
yjftsjthsd-h3 hours ago

(I like OpenBSD, but) It is extremely hard to compete with Linux on hardware support / driver coverage.

+1
johnny224 hours ago
devsda5 hours ago

Thanks Daan for your contributions to systemd.

If you were not a systemd maintainer and have started this project/company independently targeting systemd, you would have to go through the same process as everyone and I would have expected the systemd maintainers to, look at it objectively and review with healthy skepticism before accepting it. But we cannot rely on that basic checks and balances anymore and that's the most worrying part.

> that might be disruptive optional in systemd

> we don't always succeed and there will always be differences in opinion.

You (including other maintainers) are still the final arbitrator of what's disruptive. The differences of opinion in the past have mostly been settled as "deal with it" and that's the basis of current skepticism.

DaanDeMeyer5 hours ago

Systemd upstream has reviewers and maintainers from a bunch of different companies, and some independent: Red Hat, Meta, Microsoft, etc. This isn't changing, we'll continue to work through consensus of maintainers regardless of which company we work at.

s_dev5 hours ago

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

What problem does this solve for Linux or people who use Linux? Why is this different from me simply enabling encryption on the drive?

NekkoDroid5 hours ago

Drive encryption is only really securing your data at rest, not while the system is running. Ideally image based systems also use the kernels runtime integrity checking (e.g. dm-verity) to ensure that things are as they are expected to be.

+2
cwillu5 hours ago
Nextgrid5 hours ago

It prevents malware that obtained root access once from forever replacing your kernel/initrd and achieving persistence that way.

direwolf201 hour ago

Unless that malware is able to activate the secure boot feature on a system where it is not enabled, in which case it permanently prevents me from removing the malware.

trueismywork4 hours ago

systemd is the most well supported init systemd there.

Thaxll5 hours ago

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?

0x1ch6 hours ago

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

bayindirh6 hours ago

Immutability means you can't touch or change some parts of the system without great effort (e.g. macOS SIP).

Atomicity means you can track every change, and every change is so small that it affects only one thing and can be traced, replayed or rolled back. Like it's going from A to B and being able to return back to A (or going to B again) in a determinate manner.

Spivak3 hours ago

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.

jacquesm3 hours ago

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

LooseMarmoset2 hours ago

it won’t matter if you disable it. You simply won’t be able to use your PC with any commercial services, in the same way that a rooted android installation can’t run banking apps without doing things to break that, and what they’re working on here aims to make that “breakage“ impossible.

redleader556 hours ago

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

blixtra6 hours ago

As per the announcement, we’ll be building this over the next months and sharing more information as this rolls out. Much of the fundamentals can be extracted from Lennart’s posts and the talks from All Systems Go! over the last years.

dTal5 hours ago

I'm sorry, you're "happy to answer questions" and this is your reply to such a softball? What kind of questions will you answer? Favorite color?

warkdarrior3 hours ago

> Favorite color?

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

kchoudhu4 hours ago

What will they be reinventing from scratch for no reason?

MomsAVoxell3 hours ago

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

hahahahhaah6 hours ago

I'll ask the dumb question sorry!

Who is this for / what problem does it solve?

I guess security? Or maybe reproducability?

rwmj3 hours ago

My guess the problem being solved is how to get acquired by a big Linux vendor.

direwolf201 hour ago

I thought it was how to plug the user freedom hole. Profits are leaking because users can leave the slop ecosystem and install something that respects their freedom. It's been solved on mobile devices and it needs to be solved for desktops.

forty4 hours ago

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

whopdrizzard5 hours ago

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

jmclnx6 hours ago

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.

dTal6 hours ago

Verifiable to who? Some remote third party that isn't me? The hell would I want that?

murphyslaw5 hours ago

Just an assumption here, but the project appears to be about the methodology to verify the install. Who holds the keys is an entirely different matter.

dsr_4 hours ago

Werner Von Braun only built the rockets; he didn't aim them, nor did he care where they landed.

(London. On some of my relatives.)

+1
daviddever23box4 hours ago
Spivak3 hours ago

https://0pointer.net/blog/authenticated-boot-and-disk-encryp...

You. The money quote about the current state of Linux security:

> In fact, right now, your data is probably more secure if stored on current ChromeOS, Android, Windows or MacOS devices, than it is on typical Linux distributions.

Say what you want about systemd the project but they're the only ones moving foundational Linux security forward, no one else even has the ambition to try. The hardening tools they've brought to Linux are so far ahead of everything else it's not even funny.

direwolf201 hour ago

This is basically propaganda for the war on general purpose computing. My user data is less safe on a Windows device, because Microsoft has full access to that device and they are extremely untrustworthy. On my Linux device, I choose the software to install.

LooseMarmoset1 hour ago

> Microsoft

the guys that copy your bitlocker keys in the clear

advisedwang6 hours ago

The events includes a conference title "Remote Attestation of Imutable Operating Systems built on systemd", which is a bit of a clue.

jsheard6 hours ago

I'm sure this company is more focused on the enterprise angle, but I wonder if the buildout of support for remote attestation could eventually resolve the Linux gaming vs. anti-cheat stalemate. At least for those willing to use a "blessed" kernel provided by Valve or whoever.

devsda5 hours ago

Road to hell is paved with good intentions.

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.

digiown4 hours ago

That'd be too bad. Sometimes, I feel like the general public doesn't deserve general purpose computing.

direwolf206 hours ago

Only by creating a new stalemate between essential liberty and a little temporary security — anticheat doesn't protect you from DMA cheating.

+1
jsheard6 hours ago
rcxdude4 hours ago

I sincerely hope not.

poettering6 hours ago

Yes, I have.

touisteur5 hours ago

rust-vmm-based environment that verifies/authenticates an image before running ? Immutable VM (no FS, root dropper after setting up network, no or curated device), 'micro'-vm based on systemd ? vmm captures running kernel code/memory mapping before handing off to userland, checks periodically it hasn't changed ? Anything else on the state of the art of immutable/integrity-checking of VMs?

mikkupikku6 hours ago

Sounds like kernel mode DRM or some similarly unwanted bullshit.

bayindirh6 hours ago

It's probably built on systemd's Secure Boot + immutability support.

As said above, it's about who controls the keys. It's either building your own castle or having to live with the Ultimate TiVo.

We'll see.

direwolf206 hours ago

We all know who controls the keys. It's the first party who puts their hands on the device.

curt154 hours ago

And once you remove the friction for requiring cryptographic verification of each component, all it takes is one well-resourced lobby to pass a law either banning user-controlled signing keys outright or relegating them to second-class status. All governments share broadly similar tendencies; the EU and UK govts have always coveted central control over user devices.

bayindirh6 hours ago

Doesn't have to be. While I'm not a fan of systemd (my comment history is there), I want to start from a neutral PoV, and see what it does.

I have my reservations, ideas, and what it's supposed to do, but this is not a place to make speculations and to break spirits.

I'll put my criticism out politely when it's time.

zb36 hours ago

Just to make it clear - on Android you don't have the keys. Even with avb_custom_key you can't modify many partitions.

+1
bayindirh6 hours ago
youarentrightjr6 hours ago

> Sounds like kernel mode DRM or some similarly unwanted bullshit.

Look, I hate systemd just as much as the next guy - but how are you getting "DRM" out of this?

josephcsible6 hours ago

"cryptographically verifiable integrity" is a euphemism for tivoization/Treacherous Computing. See, e.g., https://www.gnu.org/philosophy/can-you-trust.en.html

omnicognate6 hours ago

As the immediate responder to this comment, I claim to be the next guy. I love systemd.

direwolf206 hours ago

Remote attestation is literally a form of DRM

+1
microtonal5 hours ago
+1
youarentrightjr4 hours ago
elcritch6 hours ago

Secure boot and attestation both generally require a form of DRM. It’s a boon for security, but also for control.

+1
youarentrightjr3 hours ago
mikkupikku6 hours ago

I don't mind SystemD.

bri3d6 hours ago

Hacker News has recently been dominated by conspiracy theorists who believe that all applications of cryptography are evil attempts by shadowy corporate overlords to dominate their use of computing.

josephcsible6 hours ago

No, it's not "all applications of cryptography". It's only remote attestation.

+1
mikkupikku4 hours ago
pjmlp4 hours ago

So I imagine Lennart Poettering has left Microsoft.

rodrigo_rata3 hours ago

Rodrigo from the Amutable team here. Yes, Lennart has left Microsoft.

shrubble5 hours ago

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.

shrubble5 hours ago

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

stackghost6 hours ago

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?

sandebert5 hours ago

Thank you for this question, it perfectly captures something that I believe many would like answered.

chaps6 hours ago

As someone who's lost many hours troubleshooting systemd failures, I would like an answer to this question, too.

microtonal5 hours ago

You won't believe how many hours we have lost troubleshooting SysV init and Upstart issues. systemd is so much better in every way, reliable parallel init with dependencies, proper handling of double forking, much easier to secure services (systemd-analyze security), proper timer handling (yay, no more cron), proper temporary file/directory handling, centralized logs, etc.

It improves on about every level compared to what came before. And no, nothing is perfect and you sometimes have to troubleshoot it.

chaps5 hours ago

"In every way"

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.

+1
notabee4 hours ago
toast05 hours ago

> systemd is so much better in every way,

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?

+1
Nextgrid5 hours ago
shrubble5 hours ago

There’s a reason why Devuan (a non systemd Debian) exists. Don’t want to get into a massive argument, but there are legitimate reasons for some to go in a different direction.

greenbit2 hours ago

And "because I want to" is a legitimate reason, if it's my system. It's not up for discussion.

+2
smartmic5 hours ago
foresto4 hours ago

Here are a few examples of problems systemd has caused me:

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.

plagiarist5 hours ago

The problem is not systemd vs SysV et al, the problem is systemd spreading like a cancer throughout the entire operating system.

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.

+2
storystarling5 hours ago
cyberax4 hours ago

> You just cannot run a system service using podman as a non-root user and have it work correctly.

Err... You just need to run `podman-compose systemd`?

I have my entire self-hosted stack running with systemd-controlled Podman, in regular user accounts.

jamespo4 hours ago

I'd be interested in what other init alternatives offer the security options systemd does

direwolf201 hour ago

It doesn't smell like DRM, it is literally DRM.

ok1234562 hours ago

amutable -k

bri3d5 hours ago

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.

cwillu4 hours ago

Like evil maid attacks, this is a vanishingly rare scenario brought out to try to justify technology that will overwhelmingly be used to restrict computing freedom.

AshamedCaptain3 hours ago

In addition, the benefit is a bit ridiculous, like that of DRM itself. Even if it worked, literally your "trusted software" is going to be running in an office full of the most advanced crackers money can buy, and with all the incentive to exploit your schema but not publish the fact that they did. The attack surface of the entire thing is so large it boggles the mind that there are people who believe on the "secure computing cloud" scenario.

bayindirh5 hours ago

You're absolutely right, but considering Windows requirements drive the PC spec, this capability can be used to force Linux distributions in bad ways.

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.

bri3d5 hours ago

> but considering Windows requirements drive the PC spec, this capability can be used to force Linux distributions in bad ways

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.

bayindirh5 hours ago

Microsoft has a "minimum set of requirements" document about "Designed for Windows" PCs. You can't sell a machine with Windows or tell it's Windows compatible without complying with that checklist.

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.

+1
bri3d4 hours ago
blibble4 hours ago

intel have had a couple of goes at this

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

microtonal6 hours ago

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!

blixtra6 hours ago

1. We are confident we have a very robust path to revenue.

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.

2b3a515 hours ago

"We are confident we have a very robust path to revenue."

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?

michaelt4 hours ago

"Ubuntu Core" is a similar product [1]

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

+3
noitpmeder4 hours ago
dang2 hours ago

We detached this subthread from https://news.ycombinator.com/item?id=46784719.

wetpaws6 hours ago

[flagged]

bijant4 hours ago

[flagged]

rvz4 hours ago

Who cares. That is all irrelevant.

I want to know if they raised VC money or not.

Either way at least it isn't anything about AI and has something to do with hard cryptography.

bijant4 hours ago

[flagged]

daviddever23box4 hours ago

[flagged]

BatteryMountain4 hours ago

[flagged]

bijant3 hours ago

[flagged]

jyoung86074 hours ago

[flagged]

bijant4 hours ago

[flagged]

phatfish3 hours ago

Just ask Google Gemini to create an About Us page for the site and you can look at that instead. I'm sure it will meet your diversity requirements.

wizzwizz44 hours ago

That's a proxy metric for what we really care about: acceptance of differences, tolerance of others, diversity of perspectives, etc. In principle, you can achieve these goals with a team whose members are all one ethnicity and gender; it's just that a fair selection process won't produce such a team often. And, as it turns out, optimising for the "people who look different" proxy metric doesn't do a terrible job of optimising for the true metric, provided the "cultural fit"-type selection effects are weak enough.

The systemd crowd are perhaps worse than GNOME, as regards "my way or the highway", and designing systems that are fundamentally inadequate for the general use-case. I don't think ethnicity or gender diversity quotas would substantially improve their decision-making: all it would really achieve is to make it harder to spot the homogeneity in a photograph. A truly diverse team wouldn't make the decisions they make.

bijant3 hours ago

[flagged]

0xbadcafebee3 hours ago

[flagged]

dang2 hours ago

No personal attacks on HN, please.

https://news.ycombinator.com/newsguidelines.html

direwolf201 hour ago

This is relevant. Every project he's worked on has been a dumpster fire. systemd sucks. PulseAudio sucks. GNOME sucks. Must the GP list out all the ways in which they suck to make it a more objective attack?

graykey314 hours ago

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.

Fischgericht2 hours ago

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.]