121 comments

[ 3.0 ms ] story [ 96.1 ms ] thread
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.

Hi, Chris here, CEO @ Amutable. We are very excited about this. Happy to answer questions.
Can you share more details at this point about what you are trying to tackle as a first step?
Can someone smarter than myself describe immutability versus atomicity in regards to current operating systems on the market?
I'll ask the dumb question sorry!

Who is this for / what problem does it solve?

I guess security? Or maybe reproducability?

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!

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?

Thank you for formulating the question we all have in such a polite way. This is a masterpiece.

Of course it will not be answered. And that's exactly an answer to your question.

Do you plan to sell this technology to laptop makers so their laptops will only run the OS they came with?
If they wanted to do that, they already would have. Do you think laptop makers need this technology to limit user freedom this way?
(comment deleted)
The first steps look similar to secure boot with TPM.
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?
"At long last, we have created the Torment Nexus from classic sci-fi novel Don't Create The Torment Nexus."
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.

> will the maintainer of systemd use their position to push this on everyone

Can you imaging the creator of systemd not to?

Good thing, without the power coming from RedHat money, the capacity of ruining the Linux ecosystem will finally be reduced!
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.
WHAT is the usage and benefit for private users? This is always neglected.

avoiding backdoors as a private person you always can only solve with having the hardware at your place, because hardware ALWAYS can have backdoors, because hardware vendors do not fix their shit.

From my point of view it ONLY gives control and possibilities to large organizations like governments and companies. which in turn use it to control citizens

it doesn't stop remote code injection. Protecting boot path is frankly hardly relevant on server compared to actual threats.

You will get 10000 zero days before you get a single direct attack at hardware

> there's no reason that remote attestation can't be used in the opposite direction

There is: corporate will fund this project and enforce its usage for their users not for the sake of the users and not for the sake of doing any good.

What it will be used for is to bring you a walled garden into Linux and then slowly incentivize all software vendors to only support that variety of Linux.

LP has a vast, vast experience in locking down users' freedom and locking down Linux.

> There is: corporate will fund this project and enforce its usage for their users not for the sake of the users and not for the sake of doing any good.

I'd really love to see this scenario actually explained. The only place I could really see client-side desktop Linux remote attestation gaining any foothold is to satisfy anti-cheat for gaming, which might actually be a win in many ways.

> What it will be used for is to bring you a walled garden into Linux and then slowly incentivize all software vendors to only support that variety of Linux.

What walled garden? Where is the wall? Who owns the garden? What is the actual concrete scenario here?

> LP has a vast, vast experience in locking down users' freedom and locking down Linux.

What? You can still use all of the Linuxes you used to use? systemd is open source, open-application, and generally useful?

Like, I guess I could twist my brain into a vision where each Ubuntu release becomes an immutable rootfs.img and everyone installs overlays over the top of that, and maybe there's a way to attest that you left the integrity protection on, but I don't really see where this goes past that. There's no incentive to keep you from turning the integrity protection off (and no means to do so on PC hardware), and the issues in Android-land with "typical" vendors wanting attestation to interact with you are going to have to come to MacOS and Windows years before they'll look at Linux.

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.

No one wants this for their computer.

These kind of technologies are forced on users.

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

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

We warned you that systemd was just the beginning.
Linux is nowadays mostly sponsored by big corporations. They have different goals and different ways to do things. Probably the first 10 years Linux was driven by enthusiasts and therefore it was a lean system. Something like systemd is typical corporate output. Due it its complexity it would have died long before finding adoption. But with enterprise money this is possible. Try to develop for the combo Linux Bluetooth/Audio/dbus: the complexity drives you crazy because all this stuff was made for (and financed by) corporate needs of the automotive industry. Simplicity is never a goal in these big companies.

But then Linux wouldn't be where it is without the business side paying for the developers. There is no such thing as a free lunch...

> the plan seems to be to replace package management with image based whole dist a/b swaps

The plan is probably to have that as an alternative for the niche uses where that is appropriate.

This majority of this thread seems to have slid on that slippery slope, and jumped directly to the conclusion where the attestation mechanism will be mandatory on all linux machines in the world and you won't be able to run anything without. Which even if it would be a purpose for amutable as a company, it's unfeasible to do when there's such a breadth of distributions and non corpo affiliated developers out there that would need to cooperate for that to happen.

Immutable, signed systems do not intrinsically conflict with hackability. See this blog post of Lennart's[0] and systemd's ParticleOS meta-distro[1].

I do agree that these technologies can be abused. But system integrity is also a prerequisite for security; it's not like this is like Digital "Rights" Management, where it's unequivocally a bad thing that only advances evil interests. Like, Widevine should never have been made a thing in Firefox imo.

So I think what's most productive here is to build immutable, signable systems that can preserve user freedom, and then use social and political means to further guarantee those freedoms. For instance a requirement that owning a device means being able to provision your own keys. Bans on certain attestation schemes. Etc. (I empathize with anyone who would be cynical about those particular possibilities though.)

[0] https://0pointer.net/blog/fitting-everything-together.html

[1] https://github.com/systemd/particleos

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

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)

fantastic news, congrats on launching! it's a great mission statement a fanstastic ensemble for the job
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?
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.

Are there VCs who participated in funding this or are you self funded?
1. Are reproducible builds and transparency logging part of your concept?

2. Are you looking for pilot customers?