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

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!

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?

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

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

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

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

2. Are you looking for pilot customers?

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?

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

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

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

I'll ask the dumb question sorry!

Who is this for / what problem does it solve?

I guess security? Or maybe reproducability?

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?

Why would you go to the effort to present faces on an "About Us" page when its only white men anyway ? Do you think Women and PoCs are incompatible with your vision of saving the Linux (not GNU, you don't mention GNU in your mission statement at all) World through germanic rigor ? Genuinely curious because you are based in Berlin where I have never been to a start-up office or techno club that wasn't at least as diverse as its SF or NYC equivalent. If you were based in Munich or Stuttgart this would be easier to pass off as a curious coincidence.

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.

systemd is the most well supported init systemd there.

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.

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

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.

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?

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.

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.

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.

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/

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.

Yes, I have.

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

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

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?

Sounds like kernel mode DRM or some similarly unwanted bullshit.

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

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.

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.