Well I was wondering when the war on general computing and computer ownership would be carried into the heart of the open source ecosystems.
Sure, there are sensible things that could be done with this. But given the background of the people involved, the fact that this is yet another clear profit-first gathering makes me incredibly pessimistic.
This pessimism is made worse by reading the answers of the founders here in this thread: typical corporate talk. And most importantly: preventing the very real dangers involved is clearly not a main goal, but is instead brushed off with empty platitudes like "I've been a FOSS guy my entire adult life...." instead of describing or considering actual preventive measures. And even if the claim was true, the founders had a real love for the hacker spirit, there is obviously nothing stopping them from selling to the usual suspects and golden parachute out.
I was really struggling to not make this comment just another snarky, sarcastic comment, but it is exhausting. It is exhausting to see the hatred some have for people just owning their hardware. So sorry, "don't worry, we're your friends" just doesn't cut it to come at this with a positive attitude.
The benefits are few, the potential to do a lot of harm is large. And the people involved clearly have the network and connections to make this an instrument of user-hostility.
I do sort of wonder if there’s room in my life for a small attested device. Like, I could actually see a little room for my bank to say “we don’t know what other programs are running on your device so we can’t actually take full responsibility for transactions that take place originated from your device,” and if I look at it from the bank’s point of view that doesn’t seem unreasonable.
Of course, we’ll see if anybody is actually engaging with this idea in good faith when it all gets rolled out. Because the bank has full end-to-end control over the device, authentication will be fully their responsibility and the (basically bullshit in the first place) excuse of “your identity was stolen,” will become not-a-thing.
Obviously I would not pay for such a device (and will always have a general purpose computer that runs my own software), but if the bank or Netflix want to send me a locked down terminal to act as a portal to their services, I guess I would be fine with using it to access (just) their services.
I suggested this as a possible solution in another HN thread a while back, but along the lines of "If a bank wants me to have a secure, locked down terminal to do business with them, then they should be the ones forking it over, not commanding control of my owned personal device."
It would quickly get out of hand if every online service started to do the same though. But, if remote device attestation continues to be pushed and we continue to have less and less control and ownership over our devices, I definitely see a world where I now carry two phones. One running something like GrapheneOS, connected to my own self-hosted services, and a separate "approved" phone to interact with public and essential services as they require crap like play integrity, etc.
But at the end of the day, I still fail see why this is even a need. Governments, banks, other entities have been providing services over the web for decades at this point with little issue. Why are we catering to tech illiteracy (by restricting ownership) instead of promoting tech education and encouraging people to both learn, and importantly, take responsibility for their own actions and the consequences of those actions.
"Someone fell for a scam and drained their bank account" isn't a valid reason to start locking down everyone's devices.
I remember my parents doing online banking authenticating with smart cards. Over 20 years ago. Today the same bank requires an iOS or Play Integrity device (for individuals at least. Their gated business banking are separate services and idk what they offer there).
> I suggested this as a possible solution in another HN thread a while back, but along the lines of "If a bank wants me to have a secure, locked down terminal to do business with them, then they should be the ones forking it over, not commanding control of my owned personal device."
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.
Yeah, to some extent I just wanted to think about where the boundary ought to be. I somewhat suspect the bank or Netflix won’t be willing to send me a device of theirs to act as their representative in my pocket. But it is basically the only time a reasonable person should consider using such a device. Anybody paying to buy Netflix or the bank a device is basically being scammed or ripped off.
Why should I need a separate device? Doesn't a hardware security token suffice? I wouldn't even mind bringing my own but my bank doesn't accept them last I checked. (Do any of them?)
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.
You shouldn't need a separate device, but we are quickly entering an era where a lot of banking (and other) apps will outright refuse to run or allow logins if it detects a rooted device, or play integrity fails.
In this way, the banks are asserting control over your device. It's beyond authentication, they are saying "If you have full control over your device, you cannot access our services."
I'll agree with you that they don't have a valid position, because I can just as easily open up a web browser on said rooted device and access just fine via the web, but how long until services move away from web interfaces in favor of apps instead to assert more control?
I have to use my phone to approve the web login to my account. My bank is working very hard to make sure that everyone uses the app for everything, including closing down offices and removing ATMs around the city.
A hardware token would not suffice. When you login with a hardware token it will generate some sort of token or cookie for further requests. This is where malware can steal that key and use it for whatever it wants. There is a benefit it knowing there is a high chance that the such a key is protected by the operating system's sandboxing technology. Without remote attestation you don't know if the sandbox is actually active or not.
On the contrary, a hardware token will suffice to thwart both phising and MitM which covers ~everything for all practical threat and liability models. What exactly is the concern here? A widespread worm that no one is yet aware of that's dumping people's bank accounts into crypto? It might make for a decent Hollywood plot but is pulling that off actually easier than attacking the bank directly?
Keep in mind that the businesses pushing this stuff still don't support U2F by and large. When I can go down in person to enroll a hardware token I might maybe consider listening to what they have to say on the subject. Maybe. (But probably not.)
Hypothetically on a fully controlled system you could prevent attacks like the sort of “hello this is Microsoft, we’ve identified a virus on your device, please download teamviewer and login to your bank account so we can clear it for you” type spam calls.
Or, hasn’t there been malware that periodically takes screenshots of the device? Or maybe that’s a Hollywood plot, I forget actually.
Keep in mind that a truly clueless user will most likely be running in a stock configuration. So long as that doesn't permit apps to tamper with one another (as is currently the case) there should be no issue. Google could even provide a toggle to officially root the phone and so long as flipping it wiped the device the problem would remain 99.9% solved because a scammer would be unable to pull the job off in one go.
By the time you reach the point that the user is doggedly following harmful step by step instructions over the course of multiple callbacks there is nothing short of a padded cell that can protect him from himself.
Unless you mean to suggest somehow screening such calls? A local LLM? Literal wiretapping via realtime upload to the cloud? If facing such a route society would likely be better off institutionalizing anyone victimized in such a manner.
It's unfortunate because it's actually incredibly useful functionality. If only they hadn't packaged and marketed it in quite the way they did. If there was ever a feature that needed to be guaranteed local only, zero third party integration, zero first party analytics, encryption tied to a TPM that was it.
Could you please spell out the specifics of this scenario?
MitM via an evil (ie incorrect) domain name is prevented because U2F (and now webauthn or CTAP2) are origin bound.
RATs? On stock android? How does that work? And how are the things you describe not also threats for online banking via a browser? It's certainly not how the vast majority of attacks take place in the wild. Can you provide any examples of such an attack (ie malware as opposed to phishing) that was widespread? Otherwise I assume we're writing a script for Hollywood here.
Even then, a RAT could be trivially defeated by requiring a second one-off token authentication for any transaction that would move money around. I doubt there'd be much objection to such a policy. If people really hate it let them opt out below an amount of their choosing by signing a liability waiver.
This is assuming the user's device is not compromised.
>How does that work?
Priviledge escalation on an old OS version allows an attacker to get root access. Then with that they can bypass any sandboxing. Or they could get access to some android permission intended for system apps that they should not have access to and use that to do malicous things.
I don't closely follow malware outbreaks for android so I can't point to specific examples, but malware does exist.
So the attacker compromises the user's device ... and then sets up a MitM? This is making about as much sense as the typical Hollywood plot that involves computers so I guess that means we're on track.
> Priviledge escalation on an old OS version allows an attacker to get root access.
At which point hardware attestation accomplishes nothing. Running in an enclave might but attesting the OS image that was used to boot most certainly won't.
Many consumers use older devices. Any banking app is forced to support them or they will lose customers. There's no way around that. (It doesn't matter anyway because these sorts of attacks simply aren't commonplace.)
> but malware does exist.
I didn't ask for an example of malware. I asked you to point to an example of a widespread attack against secured accounts using malware as a vector. You have invented some utterly unrealistic scenario that simply isn't a concern in the real world for a consumer banking interaction.
You're describing the sort of high effort targeted attack utilizing one or more zero days that a high level government official might be subject to.
>At which point hardware attestation accomplishes nothing
Attestation could be used to say that the user is not using a secure version of the OS That has known vulnerabilities patched.
>Any banking app is forced to support them or they will lose customers.
Remote attestation is just one of the many signals used for detecting fraud.
>one or more zero days
Many phones are not on an OS getting security updates. Whether that be due to age or the vendor not distributing the security patches. Even using old exploits malware can work.
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.
This entire shit storm is 100% driven by the music, film, and tv industries, who are desperate to eke a few more millions in profit from the latest Marvel snoozefest (or whatever), and who tried to argue with a straight face that they were owed more than triple the entire global GDP [0].
These people are the enemy. They do not care about about computing freedom. They don't care about you or I at all. They only care about increasing profits via and they're using the threat of locking people out of Netflix via HDCP and TPM, in order to force remote attestation on everyone.
I don't know what the average age on HN is, but I came up in the 90s when "fuck corporations" and "information wants to be free" still formed a large part of the zeitgeist, and it's absolutely infuriating to see people like TFfounders actively building things that will measurably make things worse for everyone except the C-suite class. So much for "hacker spirit".
Also worth remembering that around 2010, the music and film industry associations of America were claiming entitlement to $50 billion dollars annually in piracy-related losses beyond what could be accounted for in direct lost revenue (which _might_ have been as much as 10 billion, or 1/6th of their claim):
Yeah, as I am reading the landing page, the direction seems clear. It sucks, because as an individual there is not much one can do, and there is no consensus that it is a bad thing ( and even if there was, how to counter it ). Honestly, there are times I feel lucky to be as dumb as I am. At least I don't have the same responsibility for my output as people who create foundational tech and code.
> [T]he war on general computing and computer ownership [...] It is exhausting to see the hatred some have for people just owning their hardware.
The integrity of a system being verified/verifiable doesn't imply that the owner of the system doesn't get to control it.
This sort of e2e attestation seems really useful for enterprise or public infrastructure. Like, it'd be great to know that the ATMs or transit systems in my city had this level of system integrity.
You argument correctly points out that attestation tech can be used to restrict software freedom, but it also assumes that this company is actively pursuing those use cases. I don't think that is a given.
At the end of the day, as long as the owner of the hardware gets to control the keys, this seems like fantastic tech.
> You argument correctly points out that attestation tech can be used to restrict software freedom, but it also assumes that this company is actively pursuing those use cases. I don't think that is a given.
Once it's out there and normalized, the individual engineers don't get to control how it is used. They never do.
System integrity also ends at the border of the system. The entire ecosystem of ATM skimmers demonstrates this-- the software and hardware are still 100% sanctioned, they're just hidden beneath a shim in the card slot and a stick-on keypad module.
I generally agree with the concept of "if you want me to use a pre-approved terminal, you supply it." I'd think this opens up a world of better possibilities. Right now, the app-centric bank/media company/whatever has to build apps that are compatible with 82 bazillion different devices, and then deal with the attestation tech support issues. Conversely, if they provide a custom terminal, it might only need to deal with a handful of devices, and they could design it to function optimally for the single use case.
> At the end of the day, as long as the owner of the hardware gets to control the keys, this seems like fantastic tech.
The problem is that there are powerful corporate and government interests who would love nothing more than to prevent users from controlling the keys for their own computers, and they can make their dream come true simply by passing a law.
It may be the case that certain users want to ensure that their computers are only running their code. But the same technologies can also used to ensure that their computers are only running someone else's code, locking users out from their own devices.
That's like saying we shouldn't build anything that can be used for good if it can also be used for evil.
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?
>if I want e2e attestation of the software stack on my own devices, isn't this a good thing for me?
The building blocks are already there for a sufficiently motivated user to build their own verified OS image. Google has been doing that with ChromeOS for years. The danger I see is that once there is a low-friction, turnkey solution for locking down general purpose systems, then the battle for control over users' devices reduces to control over the keys. That is much easier for well-heeled interests to dominate than outlawing Linux outright.
The status quo is a large population of unverified but fully user-configurable systems. While the ideal end state is a large population of verified and fully user-configurable systems, it is more likely that the tools for achieving that outcome will be co-opted by corporate and political interests to bend the population toward verified and un-configurable systems. That outcome would be far worse than the status quo.
You want PCIe-6? Cool well that only runs on Asus G-series with AI, and is locked to attested devices because the performance is so high that bad code can literally destroy it. So for safety, we only run trusted drivers and because they must be signed, you have to use Redhat Premium at a monthly cost of $129. But you get automatic updates.
Do you want the control systems of the subway to get modified by a malicious actor? What about damn releases? Heat pumps in apartment buildings? Robotaxis? Payroll systems? Banks?
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.
My tinfoil hat theory is devices like HDDs will be locked and only work on "attested" systems that actively monitor the files. This will be pushed by the media industry to combat piracy. Then opened up for para-law enforcement like palantir.
Then gpu and cpu makers will hop on and lock their devices to promote paid Linux like redhat. Or offering "premium support" to unlock your gpu for Linux for a monthly fee.
They'll say "if you are a Linux enthusiast then go tinker with arm and risc on an SD card"
Remote attestation only works because your CPU's secure enclave has a private key burned-in (fused) into it at the factory. It is then provisioned with a digital certificate for its public key by the manufacturer.
Every time you perform an attestation the public key (and certificate) is divulged which makes it a unique identifier, and one that can be traced to the point of sale - and when buying a used device, a point of resale as the new owner can be linked to the old one.
They make an effort to increase privacy by using intermediaries to convert the identifier to an ephemeral one, and use the ephemeral identifier as the attestation key.
This does not change the fact that if the party you are attesting to gets together with the intermediary they will unmask you. If they log the attestations and the EK->AIK conversions, the database can be used to unmask you in the future.
Also note that nothing can prevent you from forging attestations if you source a private-public key pair and a valid certificate, either by extracting them from a compromised device or with help from an insider at the factory. DRM systems tend to be separate from the remote attestation ones but the principles are virtually identical. Some pirate content producers do their deeds with compromised DRM private keys.
In my case it is because I would never have the right amount with me, in the right denominations. Google Pay always has this covered.
Also you need to remember to take one more thing with you, and refill it occasionally. As opposed to fuel, you do not know how much you will need when.
It can get lost or destroyed, and is not (usually) replaceable.
I am French, currently in the US. I need to change 100 USD in small denominations, I will need to go to the bank, and they will hopefully do that for me. Or not. Or not without some official paper from someone.
Ah yes, and I am in the US and the Euro is not an accepted currency here. So I need to take my 100 € to a bank and hope I can get 119.39 USD. In the right denominations.
What will I do with the 34.78 USD left when I am back home? I have a chest of money from all over the world. I showed it once to my kids when they were young, told a bit about the world and then forgot about it.
Money also weights quite a lot. And when it does not weights it gets lost or thrown away with some other papers. Except if they are neatly folded in a wallet, which I will forget.
I do not care about being traced when going to the supermarket. If I need to do untraceable stuff I will get money from teh ATM. Ah crap, they will trace me there.
So the only solution is to get my salary in cash, whihc is forbidden in France. Or take some small amounts from time to time. Which I will forget, and I have better things to do.
Cash sucks.
Sure, if we go cashless and terrible things happen (cyberwar, solar flare, software issues) then we are screwed. But either the situation unscrews itself, or we will have much, much, much bigger issues than money -- we will need to go full survival mode, apocalypse movies-style.
Which does exactly what I said. Full zero knowledge attestation isn't practical as a single compromised key would give rise to a service that would serve everyone.
The solution first adopted by the TCG (TPM specification v1.1) required a trusted third-party, namely a privacy certificate authority (privacy CA). Each TPM has an embedded RSA key pair called an Endorsement Key (EK) which the privacy CA is assumed to know. In order to attest the TPM generates a second RSA key pair called an Attestation Identity Key (AIK). It sends the public AIK, signed by EK, to the privacy CA who checks its validity and issues a certificate for the AIK. (For this to work, either a) the privacy CA must know the TPM's public EK a priori, or b) the TPM's manufacturer must have provided an endorsement certificate.) The host/TPM is now able to authenticate itself with respect to the certificate. This approach permits two possibilities to detecting rogue TPMs: firstly the privacy CA should maintain a list of TPMs identified by their EK known to be rogue and reject requests from them, secondly if a privacy CA receives too many requests from a particular TPM it may reject them and blocklist the TPMs EK. The number of permitted requests should be subject to a risk management exercise. This solution is problematic since the privacy CA must take part in every transaction and thus must provide high availability whilst remaining secure. Furthermore, privacy requirements may be violated if the privacy CA and verifier collude. Although the latter issue can probably be resolved using blind signatures, the first remains.
AFAIK no one uses blind signatures. It would enable the formation of commercial attestation farms.
If I'm reading any of this correctly, this doesn't apply to hardware attestation.
It seems apple has a service, with an easily rotated key and an agreement with providers. If the key _Apple_ uses is compromised, they can rotate it.
BUT, apple knows _EXACTLY_ who I am. I attest to them using my hardware, they know _EXACTLY_ which hardware I'm using. They can ban me or my hardware. They then their centralized service gives me a blind token. But apple, may, still know exactly who owns which blind tokens.
However, I cannot generate blind tokens on my own. I _MUST_ talk to some centralized service that can I identify me. If that is not the case, then any single compromised device can generate infinite blind tokens rending all the tokens useless.
The idea behind blind signatures is that the server will give you a signed token which is blinded and you can un-blind it on your end and then use it. The consumer of the token will not be able to collude with the issuer of the token to figure out who it was given to. There is more info here: <https://blog.cloudflare.com/privacy-pass-the-math/>
I don't know if that's what Apple actually does. If it is, once it gets popular enough as an anti-bot measure there may be farms of Apple devices selling these tokens. It's a separate system from remote attestation anyhow.
I don't think that a 100% anonymous attestation protocol is what most people need and want.
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.
But what's it attesting? Their byline "Every system starts in a verified state and stays trusted over time" should be "Every system starts in a verified state of 8,000 yet-to-be-discovered vulns and stays in that vulnerable state over time". The figure is made up but see for example https://tuxcare.com/blog/the-linux-kernel-cve-flood-continue.... So what you're attesting is that all the bugs are still present, not that the system is actually secure.
It's a privacy consideration. If you desire to juggle multiple private profiles on a single device extreme care needs to be taken to ensure that at most one profile (the one tied to your real identity) has access to either attestation or DRM. Or better yet, have both permanently disabled.
Hardware fingerprinting in general is a difficult thing to protect from - and in an active probing scenario where two apps try to determine if they are on the same device it's all but impossible. But having a tattletale chip in your CPU an API call away doesn't make the problem easier. Especially when it squawks manufacturer traceable serials.
Remote attestation requires collusion with an intermediary at least, DRM such as Widevine has no intermediaries. You expose your HWID (Widevine public key & cert) directly to the license server of which there are many and under the control of various entities (Google does need to authorize them with certificates). And this is done via API, so any app in collusion with any license server can start acquiring traceable smartphone serials.
Using Widevine for this purpose breaks Google's ToS but you would need to catch an app doing it (and also intercept the license server's certificate) and then prove it which may be all but impossible as an app doing it could just have a remote code execution "vulnerability" and request Widevine license requests in a targeted or infrequent fashion. Note that any RCE exploit in any app would also allow this with no privilege escalation.
For most individuals it usually doesn’t matter. It might matter if you have an adversary, e.g. you are a journalist crossing borders, a researcher in a sanctioned country, or an organization trying to avoid cross‑tenant linkage
Remote attestation shifts trust from user-controlled software to manufacturer‑controlled hardware identity.
It's a gun with a serial number. The Fast and Furious scandal of the Obama years was traced and proven with this kind of thing
The scandal you cited was that guns controlled by the federal government don't have any obvious reasonable path to being owned by criminals; there isn't an obvious reason for the guns to have left the possession of the government in the first place.
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.
I assume the use case here is mostly for backend infrastructure rather than consumer devices. You want to verify that a machine has booted a specific signed image before you release secrets like database keys to it. If you can't attest to the boot state remotely, you don't really know if the node is safe to process sensitive data.
I'm confused. People talking about remote attestation which I thought was used for stuff like SGX. A system in an otherwise untrusted state loads a blob of software into an enclave and attests to that fact.
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.
Please don't bring attestation to common Linux distributions. This technology, by essence, moves trust to a third party distinct of the user. I don't see how it can be useful in any way to end users like most of us here. Its use by corporations has already caused too much damage and exclusion in the mobile landscape, and I don't want folks like us becoming pariahs in our own world, just because we want machines we bought to be ours...
A silver lining, is it would likely be attempted via systemd. This may finally be enough to kick off a fork, and get rid of all the silly parts of it.
To anyone thinking not possibile, we already switched inits to systemd. And being persnickety saw mariadb replace mysql everywhere, libreoffice replace open office, and so on.
All the recent pushiness by a certain zealotish Italian debian maintainer, only helps this case. Trying to degrade Debian into a clone of Redhat is uncooth.
> A silver lining, is it would likely be attempted via systemd. This may finally be enough to kick off a fork, and get rid of all the silly parts of it.
This misunderstands why systemd succeeded. It included several design decisions aimed at easing distribution maintainers' burdens, thus making adoption attractive to the same people that would approve this adoption.
If a systemd fork differentiates on not having attestation and getting rid of an unspecified set of "all the silly parts", how would they entice distro maintainers to adopt it? Elaborating what is meant by "silly parts" would be needed to answer that question.
Attestation is a critical feature for many H/W companies (e.g. IoT, robotics), and they struggle with finding security engineers who expertise in this area (disclaimer: I used to work as a operating system engineer + security engineer). Many distros are not only designed for desktop users, but also for industrial uses. If distros ship standardized packages in this area, it would help those companies a lot.
This is the problem with Linux in general. It's way too much infiltrated by our adversaries from big tech industry.
Look at all the kernel patch submissions. 90% are not users but big tech drones. Look at the Linux foundation board. It's the who's who of big tech.
This is why I moved to the BSDs. Linux started as a grassroots project but turned commercial, the BSDs started commercial but are hardly still used as such and are mostly user driven now (yes there's a few exceptions like netflix, netgate, ix etc but nothing on the scale of huawei, Amazon etc)
Linux has been majority developed by large tech companies for the last 20+ years. If not for them, it would not be anywhere close to where it is today. You may not like this fact, but it's not really a new development nor something that can be described as infiltration. At the end of the day, maintaining software without being paid to do so is not generally sustainable.
As a complete guess, I would say that 90% of Linux systems are run by "big tech drones". And also by small companies using technology.
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.
Why shouldn't they use the kernel, systemd, and a few core utilities? Why reinvent the wheel? There's nothing requiring them to pull in a typical desktop userspace.
Because different tasks requires different trade-offs and Linux has only one set of trade-offs. You cannot do good universal tool. It is like Leatherman, good enough to fix-up your bike on the side of the road, not so for normal workshop.
You say: reinvent the wheel.
I say: use pickup truck for every task, from farming to racing to commuting moving goods across continent. Is it possible? Of course. Is it good idea? I don't think so.
All cars are the same if you squint enough, wheels, engine, some frame, some controls, which are not very different between even F1 car and 18-wheel truck.
How are you defining "general-purpose OS"? Are you saying IoT and robotics shouldn't use a Linux kernel at all? Or just not your general purpose distros? I would be interested to hear more of your logic here, since it seems like using the same FOSS operating system across various uses provides a lot of value to everyone.
I think, that I want at least hard-real-time OS in any computer which can move physical objects. Linux kernel cannot be it: hard RTOS cannot have virtual memory (mapping walks is unpredictable in case of TLB miss) and many other mechanisms which are desired in desktop/server OS are ill-suited for RTOS.
Scheduler must be tuned differently, I/O must be done differently. It is not only «this process have RT priority, don't preempt it», it is design of whole kernel.
Better, this OS must be verified (as seL4). But I understand, that it is pipe dream. Heck, even RTOS is pipe dream.
About IoT: this word means nothing. Is connected TV IoT? I have no problems with Linux inside it. My lightbulb which can be turned on and off via ZigBee? Why do I need Linux here? My battery-powered weather station (because I cannot put 220v wiring in backyard)? Better no, I need as-low-power-as-possible solution.
To be honest, O think even using one kernel for different servers is technically wrong, because RDBMS, file server and computational node needs very different priories in kernel tuning too. I prefer network stack of FreeBSD, file server capabilities (native ZFS & Ko) of Solaris, transaction processing of Tandem/HPE NonStop OS and Wayland/GPU/Desktop support of Linux. But everything bar Linux is effectively dead. And Linux is only «good enough» in everything, mediocre.
I understand value of unification, but as engineer I'm sad.
I agree but it's difficult to argue against it. There is just so much you get for free by starting with a Linux distro as your base. Developing against alternatives is very expensive and developing something new is even more expensive. The best we can hope for is that someone with deep pockets invests in good alternatives that everyone can benefit from.
General purpose operating systems are fine and in some cases, preferable. However, they should be small, simple and designed with first class portability. Linux is none of those.
I'm not too big in this field but didn't many of those same IOT companies and the like struggle with the packages becoming dependent on Poeterings work since they often needed much smaller/minimal distros?
I don't think this is generally true. If you are running Linux in your stack, your device probably is investing in 1GiB+ RAM and 2GiB+ of flash storage. systemd et al are not a problem at that point. Running a UI will end up being considerably more costly.
Sure, but devices that do that are not running a Linux distro off the shelf. They are creating something custom with the minimal amount of dependencies possible.
I work on embedded devices, fairly powerful ones to be fair, and I think systemd is really great, useful software. There's a ton of stuff I can do quite easily with systemd that would take a ton of effort to do reliably with sysvinit.
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.
You already trust third parties, but there is no reason why that third party can't be the very same entity publishing the distribution. The role corporations play in attestation for the devices you speak of can be displaced by an open source developer, it doesn't need to require a paid certificate, just a trusted one. Furthermore, attestation should be optional at the hardware level, allowing you to build distros that don't use it, however distros by default should use it, as they see fit of course.
I think what people are frustrated with is the heavy-handedness of the approach, the lack of opt-out and the corporate-centric feel of it all. My suggestion would be not to take the systemd approach. There is no reason why attestation related features can't be turned on or off at install time, much like disk encryption. I find it unfortunate that even something like secureboot isn't configurable at install time, with custom certs,distro certs, or certs generated at install time.
Being against a feature that benefits regular users is not good, it is more constructive to talk about what the FOSS way of implementing a feature might be. Just because Google and Apple did it a certain way, it doesn't mean that's the only way of doing it.
Whoever uses this seeks to ensure a certain kind of behavior on a machine they typically don't own (in the legal sense of it). So of course you can make it optional. But then software that depends on it, like your banking Electron app or your Steam game, will refuse to run... so as the user, you don't really have a choice.
I would love to use that technology to do reverse attestation, and require the server that handles my personal data to behave a certain way, like obeying the privacy policy terms of the EULA and not using my data to train LLMs if I so opted out. Something tells me that's not going to happen...
I’m skeptical about the push toward third-party hardware attestation for Linux kernels. Handing kernel trust to external companies feels like repeating mistakes we’ve already seen with iOS and Android, where security mechanisms slowly turned into control mechanisms.
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.
I can see usefulness if the flow was "the device is unlocked by default, there are no keys/certs on it, and it can be reset to that state (for re-use purpose)"
Then the user can put their own key there (if say corporate policies demand it), but there is no 3rd party that can decide what the device can do.
But having 3rd party (and US one too!) that is root of all trust is a massive problem.
The giveaway is that LLMs love bulleted lists with a bolded attention-grabbing phrase to start each line. Copy-pasting directly to HN has stripped the bold formatting and bullets from the list, so the attention-grabbing phrase is fused into the next sentence, e.g. “Potential for abuse Attestation enables blacklisting”
Calling this a "giveaway" is kind of hilarious. LLMs use bulleted lists because humans have always used bulleted lists—in RFCs, design docs, and literally every tech write-up ever. Structure didn't suddenly become artificial in 2023. lol.
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?
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.
Thanks for the clarification and to be clear, I don't doubt your personal intent or FOSS background. The concern isn't bad actors at the start, it's how projects evolve once they matter.
History is pretty consistent here:
WhatsApp: privacy-first, founders with principles, both left once monetization and policy pressure kicked in.
Google: 'Don’t be evil' didn’t disappear by accident — it became incompatible with scale, revenue, and government relationships.
Facebook/Meta: years of apologies and "we'll do better," yet incentives never changed.
Mobile OS attestation (iOS / Android): sold as security, later became enforcement and gatekeeping.
Ruby on Rails ecosystem: strong opinions, benevolent control, then repeated governance, security, and dependency chaos once it became critical infrastructure. Good intentions didn't prevent fragility, lock-in, or downstream breakage.
Common failure modes:
Enterprise customers demand guarantees - policy creeps in.
Liability enters the picture - defaults shift to "safe for the company."
Revenue depends on trust decisions - neutrality erodes.
Core maintainers lose leverage - architecture hardens around control.
Even if keys are user-controlled today, the key question is architectural:
Can this system resist those pressures long-term, or does it merely promise to?
Most systems that can become centralized eventually do, not because engineers change, but because incentives do. That’s why skepticism here isn't personal — it's based on pattern recognition.
I genuinely hope this breaks the cycle. History just suggests it's much harder than it looks.
Can you (or someone) please tell what’s the point, for a regular GNU/Linux user, of having this thing you folks are working on?
I can understand corporate use case - the person with access to the machine is not its owner, and corporation may want to ensure their property works the way they expect it to be. Not something I care about, personally.
But when it’s a person using their own property, I don’t quite get the practical value of attestation. It’s not a security mechanism anymore (protecting a person from themselves is an odd goal), and it has significant abuse potential. That happened to mobile, and the outcome was that users were “protected” from themselves, that is - in less politically correct words - denied effective control over their personal property, as larger entities exercised their power and gated access to what became de-facto commonplace commodities by forcing to surrender any rights. Paired with awareness gap the effects were disastrous, and not just for personal compute.
The value is being able to easily and robustly verify that my device hasn't been compromised. Binding disk encryption keys to the TPM such that I don't need to enter a password but an adversary still can't get at the contents without a zero day.
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".
> For example I have no idea what they mean by the bullet "runtime integrity".
This is for example dm-verity (e.g. `/usr/` is an erofs partiton with matching dm-verity). Lennart always talks about either having files be RW (backed by encryption) or RX (backed by kernel signature verification).
I don’t think attestation can provide such guarantees. To best of my understanding, it won’t protect from any RCE, and it won’t protect from malicious updates to configuration files. It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware). IDSes are sufficient for this purpose, without negative side effects.
And that’s why I said “not a security mechanism”. Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.
I think all of that comes down to being a matter of what precisely you're attesting? So I'm not actually clear what we're talking about here.
Given secure boot and a TPM you can remotely attest, using your own keys, that the system booted up to a known good state. What exactly that means though depends entirely on what you configured the image to contain.
> it won’t protect from malicious updates to configuration files
It will if you include the verified correct state of the relevant config file in a merkel tree.
> It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware).
Shouldn't it permit running arbitrary binaries that you have signed? That places the root of trust with the build environment.
Now if you attempt to compile binaries and then sign them on the production system yeah that would open you up to attack (if we assume a process has been compromised at runtime). But wasn't that already the case? Ideally the production system should never be used to sign anything. (Some combination of SGX, TPM, and SEV might be an exception to that but I don't know enough to say.)
> Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.
If you remotely boot a box sitting in a rack on the other side of the world how can you be sure it hasn't been compromised? However you go about confirming it, isn't that what attestation is?
Well, maybe we're talking about different things, because I've asked from a regular GNU/Linux user perspective. That is, I have my computers and I'm concerned I would lose my freedoms to use them as I wish, because this attestation would be adopted and become de-facto mandatory if I ever want to do something online. Just like what happened to mobile, and what's currently slowly happening to other desktop OSes.
Production servers are a whole different story - it's usually not my hardware to begin with. But given how things are mostly immutable those days (shipped as images rather than installed the old-fashioned sysadmin way), I'm not really sure what to think of it...
You originally asked what the value proposition for a regular (non-corporate) user was. Then you raised some objections to my answer (or at least so I thought).
Granted these technologies can also be abused. But that involves running third party binaries that require SGX or other DRM measures before they will unlock or decrypt content or etc. Or querying a security element to learn who signed the image that was originally booted. Devices that support those things are already widespread. I don't think that's what this project is supposed to be. (Although I could always be wrong. There's almost no detail provided.)
The "founding engineers" behind Facebook and Twitter probably didn't set out to destroy civil discourse and democracy, yet here we are.
Anyway, "full control over your keys" isn't the issue, it's the way that normalization of this kind of attestation will enable corporations and governments to infringe on traditional freedoms and privacy. People in an autocratic state "have full control over" their identity papers, too.
> 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.
I am aware of that, my (personal) view is that DRM is a social issue caused by modes of behaviour and the existence or non-existence of technical measures cannot fix or avoid that problem.
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).
This whole discussion is a perfect example of what Upton Sinclair said, "It is difficult to get a man to understand something, when his salary depends on his not understanding it."
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.
Insinuation? As a sw dev they don't have any agency over whether or by whom they get acquired. Their decision will be whether to leave if it's changing to the worse, and that's very much understandable (and arguably the ethical thing to do).
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?
I'm really not trying to be slick, but I think it's quite difficult to convince people about anything concrete (such as precisely how this model is fundamentally different to models such as the Secure Boot PKI scheme and thus will not provide a mechanism to allow a non-owner of a device to restrict what runs on your machine) without providing a concrete implementation and design documents to back up what I'm saying. People are rightfully skeptical about this stuff, so any kind of explanation needs to be very thorough.
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.
>I think that technological measures cannot fix a social problem
The absence of technological measures used to implement societal problems totally does help though. Just look at social media.
I fear the outlaw evil maid or other hypothetical attackers (good old scare-based sales tactics) much less than already powerful entities (enterprises, states) lawfully encroaching on my devices using your technology. So, I don't care about "misunderstandings" of the TPM or whatever other wall of text you are spewing to divert attention.
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.
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.
> 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.
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.
> The models we have in mind for attestation are very much based on users having full control of their keys.
If user control of keys becomes the linchpin for retaining full control over one's own computer, doesn't it become easy for a lobby or government to exert control by banning user-controlled keys? Today, such interest groups would need to ban Linux altogether to achieve such a result.
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.
That's the thing. I can only provide a piece of software with the guarantee it can run on my OS. It can trust my kernel to let it run, but shouldn't expect anything more. The editor is free to run code it wants to guarantee the integrity of on its own infrastructure; but whatever reaches my machine _may_ at best run as the editor intends.
> The models we have in mind for attestation are very much based on users having full control of their keys.
FOR NOW. Policies and laws always change. Corporations and governments somehow always find ways to work against their people, in ways which are not immediately obvious to the masses. Once they have a taste of this there's no going back.
Please have a hard and honest think on whether you should actually build this thing. Because once you do, the genie is out and there's no going back.
This WILL be used to infringe on individual freedoms.
The only question is WHEN?
And your answer to that appears to be 'Not for the time being'.
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?
TLDR We already know how this will be misused to take away people's freedom not to run their own software stack but to dissent against fascism. It's immoral to build even with the best intentions.
You're providing mechanism, not policy. It's amazing how many people think they can forestall policies they dislike by trying to reject mechanisms that enable them. It's never, ever worked. I'm glad there are going to be more mechanisms in the world.
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.
Afaik bankid will actually run as long as you can install play store (IE the device don't need Google certificate), which isn't great but a little bit better than what it could have been.
That can't be right. My onyx boox note air 2 eInk tablet lets me install the google play store by registering myself as an AOSP developer and enrolling my device's serial number or GSF identifier with Google using some Google Form that some android team somewhere's automated by now. The device has no hardware security features from what I can tell. There's no way this platform would pass muster with any bank.
At least BankId (digital ID thing in Sweden) and some of the Swedish banking apps don't care about if you are rooted on stock Android. I haven't tried custom ROMs in many years, but perhaps it is time for GrapheneOS these days.
Now, if you want to use your phone as a debit/credit card substitute that is different (Google Pay cares, and I don't use it thus).
Anyway, why should banking apps care? It is not like they care when I use the bank from Firefox on my Linux laptop.
> There's no way this platform would pass muster with any bank
"Any bank"? Although the bank I use locks NFC payments behind such checks (which is not a big loss since a physical debit card offers the same functionality), anything else still works otherwise. Most of the things are available through the website (which fits well on mobile too), and mobile BLIK payments can be done from the Android app which works inside Waydroid with microG.
There's no reason other banks can't work the same way and it's outraging when they don't. Look around for a better bank.
I have the successor device, the Boox Note Air 2, and don't remember how I installed Google Play on it, it was so easy as to be not even notable. Though almost everything I use is available on F-Droid other than my fancy calendar and contacts applications.
Banks don't use these things because they provide any real security. They use them because the platform company calls it a "security feature" and banks add "security features" to their checklists.
The way you defeat things like that is through political maneuvering and guile rather than submission to their artificial narrative. Publish your own papers and documentation that recommends apps not support any device with that feature or require it to be off because it allows malware to use the feature to evade malware scans, etc. Or point out that it prevents devices with known vulnerabilities from being updated to third party firmware with the patch because the OEM stopped issuing patches but the more secure third party firmware can't sign an attestation, i.e. the device that can do the attestation is vulnerable and the device that can't is patched.
The way you break the duopoly is by getting open platforms that refuse to support it to have enough market share that they can't ignore it. And you have to solve that problem before they would bother supporting your system even if you did implement the treachery. Meanwhile implementing it makes your network effect smaller because then it only applies to the devices and configurations authorized to support it instead of every device that would permissionlessly and independently support ordinary open protocols with published specifications and no gatekeepers.
Another point is (often )the apps that banks makes are 3rd party developed by outsourcing (even if within the same developed country). If someone uses some MiTM or logcat to see some traffic and publishes it then banks get bad publicity. So to prevent this the banks, devs tell anything that is not normal (i.e) non-stock ROM is bad.
FOSS is also something many app-based software devs don't like on their products. While people in cloud, infra like it the app devs like these tools while developing or building a company but not when making end resulting apps.
Remote attestation absolutely provides increased security. Mobile banking fraud rates are substantially lower than desktop/browser banking fraud. Attestation is major reason why.
I think ever compute professional needs to spend at least a year trying to secure a random companies windows network to appreciate how impossible this actually is without hardware based roots of trust like TPMs and HSMs
It's not even that. The main reason is probably that attackers are going to be writing code to automate their attacks, and desktops are easier to develop on than phones, so that's what they use with no reason to do otherwise.
Even if you stopped supporting desktops, then they would just reverse engineer the mobile app instead of the web app and extract the attestation keys from any unpatched model of phone and still run their code on a server, and then it would show up as "mobile fraud" because they're pretending to be a phone instead of a desktop, when in reality it was always a server rather than a phone or a desktop.
And even if attestation actually worked (which it doesn't), that still wouldn't prevent fraud, because it only tries to prove that the person requesting the transfer is using a commercial device. If the user's device is compromised then it doesn't matter if it can pass attestation because the attacker is only running the fake, credential stealing "bank app" on the user's device, not the real bank app. Then they can run the official bank app on an official device and use the stolen credentials to transfer the money. The attestation buys you nothing.
All this theatre is turning out to be nothing more than giving up the agency we have today (nice things), for a risk averse kneejerk runaround with glaring ulterior motives...just like the scan your face+id push for services.
Would YOU be willing to use a bank that refused to use TLS? I didn't think so. How is you refusing to accept remote attestation and the bank refusing to connect to you any different?
Because Banking has existed and operated fine for countless decades without it(attestation).
Also, as there is ample discussion elsewhere, having attestation does NOT eliminate the ability for your account to become compromised.
As restated.
"If the user's device isn't compromised then everything is fine regardless of whether or not it can pass attestation. If the user's device is compromised, the device doesn't need to pass attestation to run a fake bank app and steal the user's credentials. Once the attacker has the user's credentials they can use them to transfer money regardless of whether or not they have to use a different device that can pass attestation.
It doesn't really provide any security."
IT DOES however completely rewrite the paradigm of general purpose computing in very asymmetrical ways.
If the user's device isn't compromised then everything is fine regardless of whether or not it can pass attestation. If the user's device is compromised, the device doesn't need to pass attestation to run a fake bank app and steal the user's credentials. Once the attacker has the user's credentials they can use them to transfer money regardless of whether or not they have to use a different device that can pass attestation.
It doesn't really provide any security.
On top of that, there are tons of devices that can pass attestation that have known vulnerabilities, so the attacker could just use one of those (or extract the keys from it) if they had any reason to. But in the mobile banking threat model they don't actually need to.
It's not a matter of being hard. It's like trying to prevent theft by forcing everyone to wear a specific brand of shoes. The fact that the shoe company insists that it's useful is not evidence that it is.
It's not that you can't solve the problem, it's that you can't solve the problem using that mechanism. Attestation is useless for this.
The thing that would actually work for this is to have an open standard supported by PCs and phones to read the chip in payment/ATM cards, because then you could do "card-present" transactions remotely. You touch your card to the phone/PC and enter your PIN to authorize a new merchant. That actually solves the problem because then instead of the bank trusting every commercially available phone on the market, they only trust the specific card that they mailed to the cardholder, and you can only authorize a new merchant with physical possession of the card because it contains a private key. But that doesn't require attestation because then you don't need the keys to be in the phone since they're in the card, and it doesn't require a third party to sign anything because the bank puts the private key into the card before sending it to the cardholder without any need for Google or Apple to certify anything.
Well, it depends. I can now do banking from my desktop computer because there is no way our banks can attest that we're running our browsers in their approved hardware+software stack. Of course they can already disable banking from the browser but if they choose to keep it open but require attestation in your browser when it becomes possible, I don't think it's a good thing.
It would but how and who to run it? Ideally some one like Linux Foundation sits on the White house meetings or EU meetings. But they don't. Govts don't understand. I was once participating in a Youth meeting with MEPs - most of them have only iPhones. Most (not all) lawmakers live on a different planet.
Also IIRC, linux foundation etc are not interested in doing such standardisations.
This is already the world you live in just running some recent Ubuntu. Try writing, building and loading a kernel module!
Of course its all nonsense make believe, the "trust root" is literally a Microsoft signed stub. For this dummy implementation you can't modify your own kernel anymore.
Torrenting is becoming more popular again. The alternative to being allowed to pay to watch on an "insecure" device isn't switching to an attested device, it's to stop paying for the content at all. Games industry, same thing (or just play the good older games, the new ones suck anyway).
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.
As an end user hand assembling desktop services on non-Systemd distros (Artix, Devuan, Gentoo, Guix) over the years, and thus had no concern about APIs, Pipewire just works and PulseAudio gave endless trouble.
As another user on Gentoo, pipewire is a never ending pain in the ass full of "magic" behavior and weird bugs. I mostly skipped pulse though so it may be simple in comparison to that.
There were dozens of other init systems that, like systemd, wasn't a shell script.
What set systemd apart is the collection of tightly integrated utilities such as a dns resolver, sntp client, core dump handler, rpc-like api linking to complex libraries in the hot path and so on and so forth that has been a constant stream of security exploits for over a decade now.
This is a case where the critics were proven to be right. Complexity increases the cognitive burden.
As predicted. I thought pulseaudio should have been enough of a lesson. Besides that, any person that works on open source but that joins Microsoft is not in the camp that should have a say in the overall direction of Linux.
that on itself is not a problem. The problem is that those work worse.
For example, the part of systemd that fills DNS will put them in random order (like actual random, not "code happened to dump it in map order)
The previous, while very much NOT perfect, system, put the DNSes in order of one in latest interface, which had useful side-feature that if your VPN had different set of DNSes, it got added in front
The systemd one just randomizes it ( https://github.com/systemd/systemd/issues/27543 ) which means that using standard openvpn wrapper script for it will need to be reran sometimes few times to "roll" the right address, I pretty much have to run
Like, they decided to use binary log format. Okay, I can see advantages, it can be indexed or sharded for faster access to app's files...
oh wait it isn't, if you want to get last few lines of a service the worst case is "mmap every single journal file for hundreds of MBs of reads"
It can be optimized so some long but constant fields like bootid are not repeated...
oh wait it doesn't do that either, is massively verbose. I guess I can understand it, at least that would make it less crash-proof...
oh wait no, after crash it just spams logs that previous log file is corrupted and it won't be used.
So we have a log format that only systemd tools can read, takes few times as much space per line as text or even JSON version would, and it still craps out on unclean shutdown
They could've just integrated SQLite. Hell I literally made a lil prototype that took journalctl logs and wrote it to indexed SQLite file and it was not only faster but smaller (as there is no need to write bootid with each line, and log lines can be sharded or indexed so lookup is faster). But nah, Mr. Poettering always wanted to make a binary log format so he did.
The trick is the same: use a popular linux distribution and don't fight the kinks.
The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way.
SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work that makes systemd function smooth.
I was today years old when I realised this is true for both bits of poetter-ware. Weird.
pulseaudio I had to fight every single day, with my "exotic" setup of one set of speakers and a headset
with pipewire, I've never had to even touch it
systemd: yesterday I had a network service on one machine not start up because the IP it was trying to bind to wasn't available yet
the dependencies for the .service file didn't/can't express the networking semantics correctly
this isn't some hacked up .service file I made, it's that from an extremely popular package from a very popular distro
(yeah I know, use a socket activated service......... more tight coupling to the garbage software)
the day before that I had a service fail to start because the wall clock was shifted by systemd-timesyncd during startup, and then the startup timeout fired because the clock advanced more than the timeout
then the week before that I had a load of stuff start before the time was synced, because chrony has some weird interactions with time-sync.target
it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc
for what? to save maybe a second of boot time
if the distro maintainers don't understand the systemd dependency model after a decade then it's unfit for purpose
> it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc
This gave me a good chuckle. Systemd literally was created to solve the awful race conditions and non-determinism in other init systems. And it has done a tremendous job at it. Hence the litany of options to ensure correct order and execution: https://www.freedesktop.org/software/systemd/man/latest/syst...
And outside of esoteric setups I haven't ever encountered the problems you mentioned with service files.
systemd was created to solve the problems of a directory full of shell scripts. A single shell script has completely different problems. And traditional init uses inittab, which is not /etc/init.d, and works more like runit.
runit's approach is to just keep trying to start the shell script every 2 seconds until it works. One of those worse–is–better ideas, it's really dumb, and effective. You can check for arbitrary conditions and error–exit, and it will keep trying. If you need the time synced you can just make your script fail if the time is not synced.
traditional inittab is older than that and there's not any reason to use it when you could be using runit, really.
yeah, many options that are complicated beyond the understanding of the distro maintainers, and yet still don't allow expression of common semantics required to support network services reliably
like "at least one real IP address is available" or "time has been synced"
and it's not esoteric, even ListenAddress with sshd doesn't even work reliably
the ONLY piece of systemd I've not had problems with is systemd-boot, and then it turned out they didn't write that
> like "at least one real IP address is available" or "time has been synced"
"network-online.target is a target that actively waits until the network is “up”, where the definition of “up” is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network has been set up."
For time sync checks, I assume one of the targets available will effectively mean a time sync has happened. Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one.
Are you running this particular unit file as a user unit or a system unit? Some targets like network-online.target don't work from user unit files.
You could also try targeting NetworkManager or networkd's "wait-online" services. Or if that doesn't work, something is telling systemd that you have an IP when you don't. NetworkManager has "ipv4.may-fail" and "ipv6.may-fail" that might be errenously true.
> at that point I might as well go back to init=/etc/rc
The difference is that systemd is much better at ensuring correctness. If you write the invoked shell command properly, it'll communicate failure or success correct and systemd will then communicate that state to the unit. It's still a lot more robust than before.
Seems like you have an axe to grind with systemd because it replaced your familiar (but extremely cruddy) init system and now you refuse to debug the problem because you prefer being able to blame systemd.
There is so much granularity and flexibility in what you can do it seems rather unlikely you cannot make it happen correctly. And if it is truly a bug... open an issue? They're rather responsive to it. And it isn't like the legacy init systems were bug free from inception (well, lord knows they were still chock full of bugs even when they were replaced).
Edit: sitting here with a grin
.. HN downvoting the advice of checking logs, debugging and opening an issue. I wish the companies y'all work at good luck.. they'll need it.
> Seems like you have an axe to grind with systemd because it replaced your familiar (but extremely cruddy) init system and now you refuse to debug the problem because you prefer being able to blame systemd.
I'm a pragmatist: I just want it to work
my solution to MULTIPLE different services failing to IP bind is to turn on the non-local ip binding sysctl, bypassing systemd's brokenness entirely
> There is so much granularity and flexibility in what you can do it seems rather unlikely you cannot make it happen correctly.
I've written an init before (in C), I know how the netlink interface to set an IP address and add routing table entries works
I understand the difference between monotonic and wall clocks
I understand the difference between Wants and Require
I know what's going on at every, single, level
and I can't stand how unreliable systemd makes nearly every single one of my, bluntly, completely vanilla systems
> And if it is truly a bug... open an issue?
did you read the link I pasted earlier?
I'm not wasting my time with that level of idiocy (from LP himself)
I'm not a systemd hater or anything, but I continue to read stuff from Poettering which to me is deeply disturbing given the programs he works on.
Saying it's not a bug that service is launched despite a stated required prerequisite dependency failed... WTF?
Sure, I agree with him that most computers should probably boot despite NTP being unable to sync. But proposing that the solution to that is breaking Requires is just wild to me.
I'm not sure I understand why you think the solution proposed there is so bad.
The question in that issue is around the semantics of time-sync.target. Targets are synchronization points for the system and don't (afaik) generally make promises about the units that are ordered before them (in this case chrony-wait.service.
Does that answer your specific objection of "proposing that the solution to that is breaking Requires is just wild to me"? Basically, what is proposed in that issue is not breaking Requires=. The proposition is that the user add their own, specific Requires= as a drop-in configuration since that's not a generally-applicable default.
No, that does not make sense, because it goes against the systemd documentation.
Targets[1]: Target units do not offer any additional functionality on top of the generic functionality provided by units. They merely group units, allowing a single target name to be used in Wants= and Requires= settings to establish a dependency on a set of units defined by the target, and in Before= and After= settings to establish ordering.
boot-complete.target[2]: Order units that shall only run when the boot process is considered successful after the target unit and pull in the target from it, also with Requires=.
Note use of "only run" with a reference to Requires=.
time-sync.target[3]: This target provides stricter clock accuracy guarantees than time-set.target (see above), but likely requires network communication and thus introduces unpredictable delays. Services that require clock accuracy and where network communication delays are acceptable should use this target.
Especially note the last sentence there.
The documentation clearly indicates that targets can fail, and that services that needs the target to be successful, should use Requires= to specify that.
If the above is not true, the Requires= and Targets documentation should be rewritten to explicitly say that targets might fulfill Requires= regardless of state. Also, the documentation for time-sync.target should explicitly remove the last sentence and instead state there is no functional difference between Requires=time-sync.target and Wants=time-sync.target, it is best-effort only.
If he really don't want targets to deliver failed/success guarantees, then they've massively miscommunicated in their documentation. That in my book is a huge deal.
In either case the issue should in no circumstance be casually dismissed as not-a-bug without further action.
I don't personally find it as disturbing as you do, I think. Which isn't to say that I don't think it should be fixed, etc. etc.
I'm sure the project would accept a documentation patch to amend this discrepancy. At the end of the day (despite what some people on the internet might like to allege), systemd is a free software project that, despite having (more or less) a BIFL, is ultimately a relatively bazaar-like project.
Though since these targets and unit properties are very core to systemd-the-service manager, I do think that this is a bigger documentation oversight than most.
The disturbing part isn't the bug in time-sync.target or documentation, the disturbing part is how casually he brushes the issue away.
To me this is a huge red flag for a senior contributer to a core systems component, signalling some fundamental lack of understanding or imagination.
I very much disagree with not fixing time-sync.target, but if he had instead written a well-reasoned explanation for why time-sync.target should not propagate failed states and flagging it as a documentation bug, then that's something I'd respect and would be fine with. Or, even better IMHO, he'd fix time-sync.target and state that users who wants to boot regardless should use Wants instead.
That's entirely defined by whatever units order themselves before network-online.target (normally a network management daemon like NetworkManager or systemd-networkd). systemd itself doesn't define the details; that's left up to how that distro and sysadmin have configured the network manager/system.
Same. I run a server with a ton of services running on it which all have what I think are pretty complex dependency chains. And I also have used Linux with systemd on my laptop. Systemd has never, once, caused me issues.
I can totally relate to this, it's gotten to the point that I'm just as scared of rebooting my Linux boxes as I was of rebooting my windows machine a couple of decades ago. And quite probably more scared.
The only parties that really cared about boot time were the big hosting providers and container schleppers. For desktop linux it never mattered as much.
PipeWire was also made by a guy with a lot of multimedia experience (GStreamer).
ALSA was kind of OK after mixing was enabled by default and if you didn't need to switch outputs of a running application between anything but internal speakers and headphones (which worked basically in hardware). With any additional devices that you could add and remove, ALSA became a more serious limitation, depending. You could usually choose your audio devices (including microphones) at least at the beginning of a video conference / playing a movie etc, but it was janky (unreliable, list of 20 devices for one multi-channel sound card) and needed explicit support from all applications. Not sure if it ever worked with Bluetooth.
I still need to use alsamixer to unmute my headphones after accidentally unplugging them and plugging them in again fails to do so. That's with PipeWire - never had that problem with just ALSA.
Eh, I had to do that with pulseaudio too, but constantly, across all distros and headphones. Pipewire is shonky, I have to restart now and then on my steam deck (I'm using it as a desktop), but it's still much better than pulseaudio. Even ALSA was better than pulseaudio lol
I got stuck for two weeks installing the kernel because I forgot to mount /boot. Perhaps I disabled it by accident when goofing around in alsamixer? Or my card did or didn't have hardware mixing?
I didn't actually know anything about Linux at the time and started with Gentoo because I saw a meme saying "install Gentoo" and people told me not to start with that distro. So it's possible I messed up the default config by accident.
That's because systemd originated at RedHat. If it had been designed distribution agnostic it would have worked a lot better on other distros besides RH.
What are the non-distribution agnostic parts of systemd? Considering it runs as PID1 (usually) it kinda is the base of distros and not really built on top of any distro other than "the linux kernel".
"The trick is the same: use a popular linux distribution and don't fight the kinks."
I believe that you are genuinely being sincere here, thinking this is good advice.
But this is an absolutely terrible philosophy. This statement is ignorant as well as inconsiderate. (again, I do believbe you don't intend to be inconsiderate consciously, that is just the result.)
It's ignorant of history and inconsiderate of everyone else but yourself.
Go back a few years and this same logic says "The trick is, just use Windows and do whatever it wants and don't fight."
So why in the world are you even using Linux at all in the first place with that attitude? For dishonest reasons (when unpacked to show the double standard).
Since you are using Linux instead of Windows, then you actually are fine with fighting the tide. You want the particular bits of control you want, and as long as you are lucky enough to get whatever you happen to care about without fighting too much, then you have no sympathy for anyone else who cares aboiut anything else.
You don't see yourself as fighting any tides because you are benefitting from being able to use a mainstream distro without customizing it. But the only reason you get to enjoy any such thing at all in the first place is because a lot of other people before you fought the tide to bring some mainstream distros into existence, and actually use them for ordinary activities enough despite all the difficulties, to force at least some companies and government agencies to acknowledge them. So now you can say things like "just use a mainstream distro as it comes and don't try to do what you actually want".
> Go back a few years and this same logic says "The trick is, just use Windows and do whatever it wants and don't fight."
This is basically exactly what I saw people saying in Windows subreddits. There's one post that particularly sticks out in my memory[0] that basically had everybody telling the OP to just not make any of the changes that they wanted to make. The advice seemed to revolve around adapting to the OS rather than adapting the OS to you, and it made me sad at the time.
> The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way.
Incorrect. I used mainstream distro, still had issues, that just solved itself moving to pipewire. Issues like it literally crashing or emitting spur of max volume noise once every few months for no discernable reason.
Pulseaudio also completely denies existence of people trying to do music on Linux, there is no real way to make latency on it be good.
> SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work that makes systemd function smooth.
Over the years of using the "opinion" of SystemD seems to be "if it is not problem on Lennart's laptop, it's not a real problem and it can be closed or ignored completely".
For example systemd have no real method to tell it "turn off all apps after 5 minutes regardless of what silly package maintainers think". Now what happens if you have a server on UPS that have say 5 minutes of battery and one of the apps have some problem and doesn't want to close?
In SysV, it gets killed, and system gets remounted read only. You have app crash recovery but at least your filesystem is clean
In systemd ? No option to do that. You can set default timeout but it can be override in each service so you'd have to audit every single package and tune it to achieve that. That was one bug that was closed.
Same problem also surfaced if you have say app with a bug that prevented it from closing from sigterm and you wanted to reboot a machine. Completely stuck
But wait, there is another method, systemd have an override, you can press (IIRC) ctrl+alt+delete 7 times within 2 seconds to force it to restart ( which already confuses some people that expect it to just restart machine clean(ish) regardless https://github.com/systemd/systemd/issues/11285 ).
...which is also impossible if your only method of access is software KVM where you need to navigate to menu to send ctrl+alt+del. So I made ticket with proposal to just make it configurable timeout for the CAD ( https://github.com/systemd/systemd/issues/29616 ), the ticket wasn't even read completely because Mr. Poettering said "this is not actionable, give a proposal", so I pasted the thing he decided to ignore in original ticket, and got ignored. Not even "pull requests welcome" (which I'd be fine with, I just wanted confirmation that the feature like that won't be rejected if I start writing it).
There is also issue of journald disk format being utter piece of garbage ("go thru entire journal just to get app's last few lines bad", hundreds of disk reads on simple systemctl status <appname> bad) that is consistently ignored thru many tickets from different people.
Or the issue that resolvconf replacement in systemd will just roll a dice on DNS ordering, but hey, Mr. Lennart doesn't use openvpn so it's not real issue ( https://github.com/systemd/systemd/issues/27543 )
I'm not writing it to shit on systemd and praise what was before, as a piece of software it's very useful for my job as sysadmin (we literally took tens of thousands lines of fixed init scripts out because all of the features could be achieved in unit files) and I mean "saved tons of time and few demons running" in some cases, but Mr. Poettering is showing same ignorant "I know better" attitude he got scolded at by kernel maintainers.
> Pulseaudio also completely denies existence of people trying to do music on Linux, there is no real way to make latency on it be good.
I don't care much about PA at this point tbh and don't know much about the inner workings; it always worked just fine for me. But from what I read from people more "in the know" at the time, I'd heard that a lot of the (very real) user-facing problems with PA were ultimately caused by driver and other low-level problems. Those were hacky, had poor assumptions, etc. PA ultimately exposed those failures, and largely got better over time because those problems got fixed upstream of PA.
My takeaway from what I read was basically that PA had to stumble and walk so that pipewire could run.
> For example systemd have no real method to tell it "turn off all apps after 5 minutes regardless of what silly package maintainers think". Now what happens if you have a server on UPS that have say 5 minutes of battery and one of the apps have some problem and doesn't want to close?
Add a TimeoutStopSec= to /etc/systemd/system/service.d/my-killing-dropin.conf more or less, I think? These are documented in the systemd.service and systemd.unit manpages respectively.
> Same problem also surfaced if you have say app with a bug that prevented it from closing from sigterm and you wanted to reboot a machine. Completely stuck
See the --force option on the halt, poweroff, and reboot subcommands of systemctl. The kill subcommand if you want to target that specific service.
> so I pasted the thing he decided to ignore in original ticket, and got ignored. Not even "pull requests welcome" (which I'd be fine with, I just wanted confirmation that the feature like that won't be rejected if I start writing it).
I'm certainly sympathetic to this pain point. I'd take Lennart at his word that he's not opposed. Generally speaking, from following the systemd project somewhat, it's a very busy project and it's hard for all issues to get serviced. But they're very open to PRs, generally speaking.
> Or the issue that resolvconf replacement in systemd will just roll a dice on DNS ordering, but hey, Mr. Lennart doesn't use openvpn so it's not real issue ( https://github.com/systemd/systemd/issues/27543 )
Quickly taking a peek here (and speaking as a relatively superficial user of resolved myself), isn't the proposed solution to define interface ordering?
> it will ask on all links in parallel if there's no better routing info available. In your case there is none (i.e. no ~. listed among your network interfaces), hence it will be asked on all interfaces at the same time.
It's baffling to me that anyone can imagine pipewire has been created from scratch without any lessons learned from pulseaudio and the previous issues the audio stack on linux had, and solved, over the years. Nothing is happening in a clean room bubble, every new project stands on the shoulders of giants...
agent Smith, the one that don't care at all about conforming to POSIX?
"In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!"
--
https://archive.fosdem.org/2011/interview/lennart-poettering...
Poettering gas a track record of recognizing good ideas from Apple, then implementing them poorly. He also has a track record of closing bug reports for plain and simple bugs in his software to protect his own ego, and this kind of mentality isn't a great basis for security sensitive software.
Audio server for linux: Great idea! Pulseaudio: Genuinely a terrible implementation of it, Pipewire is a drop in replacement that actually works.
Launchd but for Linux: Great idea! SystemD: generally works now at least, but packed with insane defaults and every time this is brought up with the devs they say its the distro packagers jobs to wipe SystemD's ass and clean up the mess before users see it.
Security bug in SystemD when the user has a digit in their username: Lennart closes the bug and says that SystemD is perfect, the distros erred by permitting such usernames. Insane ego-driven response.
He really will just close a ticket because he disagrees with how Linux works. I read about systemd sysusers and thought they would be neat for running containerized services. But Poettering doesn't like the /etc/subuid files and refuses to work with them.
How do I have nsresourced work in a regular systemd service or quadlet so that I can have an ephemeral user run a container? I am trying to find information and just seeing it as part of nsspawn, that seems to require a container specifically built around a root filesystem.
I am not going to struggle with systemd if I have to build containers specifically for it. If I have to rearrange everything I am doing I would just learn to do it on a minimal Kubernetes install instead.
nspawn containers aren't really any different to regular system images/archives other than they don't need a kernel.
I don't think the setting is exposed to regular service units (it might be able to in the future, I don't know) and I don't think podman has any integration with it.
What kinda service do you have where you need a full range of UIDs?
I don't need a full range. I would just like to run podman under a non-root user using regular system services. Especially where a persistent volume or bind mount is involved.
Let's say Home Assistant. It would be nice to have a have some system user "homeassistant" with no home directory that owns the process and owns its /var/whereever/config.conf . It would be nice to have the isolation on host in addition to the isolation via container. But I don't want to be rebuilding any containers to get that, unless I am misunderstanding something on nsresourced.
I'd be really pleased with that setup. MQTT could be its own system user. And HA could depend on MQTT so I have nice startup behavior. Etc.
IDK how to have system users like this run a container without the subuid range. Even when I create the users with ranges in the file, there seems to be problems with informing systemd (as a non-root user) that the running process is different from the one it started.
podman quadlet doesn't seem to support running at a "system level" as a non-root user, at least according to their docs[0]. I assume they make some assumptions which wouldn't hold up if the user actually changed when running at a system level, dunno.
> But I don't want to be rebuilding any containers to get that, unless I am misunderstanding something on nsresourced.
Setting up the user namespace would be part of the container manager and not the containers themselves, so they shouldn't need any rebuilding or special handling (possibly the files might need to be shifted into the "foreign ID" range[1, 2], but I might be lying with this and this isn't necessary for this usecase) but the container manager needs to be specifically make use of nsresourced.
I really think currently the best option is to go with either systemd as your "container manager" (e.g. just regular system files with sandboxing or nspawn images or maybe systemd-portabled[3]) or podman as your container manager. As much as I too would love to mix them, I don't think it's the best idea (at least in the current state) and just go with what is more suited for the task (in your case it sounds like podman would be the most suited option).
> there seems to be problems with informing systemd (as a non-root user) that the running process is different from the one it started.
Yea, I don't think systemd likes double forking. The best option would be to keep the process that spawned your actual process alive until the child exists and just bubble up the exit code. There is the `PIDFile=` option with `Type=forking`, but I haven't used it, nor looked much into it.
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.
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.
here is some actual security: encrypted /boot, encrypted everything other than the boot loader (grub in this case)
sign grub with your own keys (some motherboards let you to do so). don't let random things signed by microsoft to boot (it defeats the whole point)
so you have grub in an efi partition, it passes secure boot, loads, and attempts to unlock a luks partition with the user provided passphrase. if it passed secure boot it should increase confidence that you are typing you password into the legit thing
so anyway, after unlocking luks, it locates the kernel and initrd inside it, and boots
the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech
however, this is still better than, at failure, letting anything run
sophisticated attackers will defeat this, but they can also add a variety of attacks at hardware level
I’d much rather have tamper detection. Encryption is great should the device is stolen but it feels like the wrong tool for defending against evil maids. All I’d want is that any time you open the case or touch the cold external ports (ie unbolted) you have to re-authenticate with a master password. I’m happy to use cabled peripherals to achieve this.
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.
Sorry, I wasn’t clear enough. We’re talking about three things here:
(1) Encryption: fast and fantastic, and a must-have for at-rest data protection.
It is vulnerable to password theft though. An attacker might insert evil code between power-on and disk-password-entry. With a locked down BIOS / UEFI, the only way to insert the code is to take the boot drive out of the device, modify it, put it back, and hope no one notices. “Noticing” in this case is done by either:
(2) Trust chaining: verify the signatures of the entire boot process to detect evil code.
(3) Tamper detection: verify the physical integrity of the device.
My point is that (1) is a given, and out of (2) or (3), I’d rather have the latter than deal with the shoddiness of the former
> the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech
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...
Doing secure boot properly is kind of difficult. There are a bunch of TPM measurement registers for various bits and bobs (kernel, initramfs, cmdline, lots more). Using UKIs simplifies it a lot, but it’s not trivial to do right at the moment.
Same with remote attestation. Not all implementations are actually secure. But hopefully over time those security bugs can be ironed out and the cost to extract a key be made infeasable.
Hopefully not. What you have just said is a synonym for "But hopefully over time manufacturers will be able to completely prevent users from running unapproved software."
In the case of video game consoles that could be the case. It turned out that being able to run unapproved software results mainly in people playing pirated games. These security measures are reactive to the actions other people have taken. We already experimented with computing being the wild west where there was little to no security. It turned out that bad actors will abuse anything they can find. Even if it's not economical some attackers will still cause abuse.
There's always going to be a market for computers that can run unapproved software. I don't see that going away.
There is the integrity measurement architecture but it isn't very mature in my opinion. Even secureboot and module signing is a manual setup by users, it isn't supported by default, or by installers. You have to more or less manage your own certs and CA, although I did notice some laptops have debian signing keys in UEFI by default? If only the debian installer setup module signing.
But you miss a critical part - Secure Boot, as the name implies is for boot, not OS runtime. Linux I suppose considers the part after initrd load, post-boot perhaps?
I think pid-1 hash verification from the kernel is not a huge ask, as part of secure boot, and leave it to the init system to implement or not implement user-space executable/script signature enforcement. I'm sure Mr. Poettering wouldn't mind.
It is not useless. I'm using UKI, so initrd is built into the kernel binary and signed. I'm not using bootloader, so UEFI checks my kernel signature. My userspace is encrypted and key is stored in TPM, so the whole boot chain is verified.
Yes, you can. I really don't want to be in the business of building OSes. If these guys make it so that getting reasonable boot security is a simple toggle, I'd be grateful.
On arch it isn't particularly difficult to create UKIs other than changing like 2 lines in `mkinitcpio`'s config.
Then there is also `ukify` by systemd which also can create UKIs, which then can be installed with `kernel-install`, but that is a bit more work to set up than for `mkinitcpio`.
The main part is the signing, which I usually have `sbctl` handle.
Isn’t the idea that the kernel will verify anything beneath it. Secure boot verifies the kernel and then it’s in the hands of the kernel to keep verifying or not.
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.
Standardizing that approach is one thing that the systemd project has been working on. They've built various components to help with that, including writing specifications (via the UAPI group) on how that should all fit together.
ParticleOS[0] gives a look at how this can all fit together, in case you want to see some of it in action.
> 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.
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.
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.
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.
> you cannot use unsigned drivers because the kernel can detect and activate the lockdown mode
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).
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)
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.
This happens much less frequently than the manufacturer of "my" computing device verifies that I haven't tampered with it. On net, it's a wholesale destruction of user freedom.
"it's a wholesale destruction of user freedom." This is ridiculously hyperbolic language for what are basically fancy digital signatures. There is nothing stopping you from using two different systems, one that passes attestation and one that doesn't.
The better question then is why the actual f** can an OTA firmware update touch anything in the steering or powertrain of the car, or why do I even need a computer that's connected to anything, and one which does more than just make sure I get the right amount of fuel and spark, or why on earth do people tolerate this sort of insanity.
If a malicious update can be pushed because of some failure in the signature verification checks (which already exist), what makes you think the threat actor won’t have access to signing keys?
This is not what attestation is even seeking to solve.
Firmware upgrades don't need to use the same protocols. Without secure boot any applet can take a security hole escalate and persist until you take a trip to a zone of interest.
With secure-boot+attestation, the vendors can choose not to let you download the latest map data, report you to the authorities, etc.
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.
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?
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.
> 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.
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.
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.
Banks do this because they have made their own requirement that the mobile device is a trust root that can authenticate the user. There are better, limited-purpose devices that can do this, but they are not popular/ubiquitous like smartphones, so here we are.
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.
> 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.
Don't get me wrong, I'm happy to attribute a lot of malice to Microsoft, but in this case I really do believe that it was incompetence. Everything I've ever read about 90%+ of hardware vendors is that shipping hilariously broken firmware is an everyday occurrence for them.
This reminds me of when I enrolled only my own keys into a gigabyte AB350 and I just soft-bricked it because presumably some opt-rom required MS keys.
I exchanged it for an Asrock board and there I can enable secure boot without MS keys and still have it boot cuz they actually let you choose what level of signing the opt-rom needs when you enable secure boot.
What I want to say with this is that it requires the company to actually care to provide a good experience.
Note that the comment you replied to does not even mention phones. Locked down Secure Boot on UEFI is not uncommon on mobile platforms, such as x86-64 tablets.
I wish the myth of the spec would die at this point.
Many motherboards secure boot implimentation violates the supposed standard and does not allow you to invalidate the pre-loaded keys you don't approve of.
It's interesting how quickly the OSS movement went from "No, no, we just want to include companies in the Free Software Movement" to "Oh, don't worry, it's ok if companies with shareholders that are not accountable to the community have a complete monopoly on OSS, and decide what direction it takes"
FOSS was imagined as a brotherhood of hackers, sharing code back and forth to build a utopian code commons that provided freedom to build anything. It stayed firmly in the realm of the imaginary because, in the real world, everybody wants somebody else to foot the bill or do the work. Corporations stepped up once they figured out how to profit off of FOSS and everyone else was content to free ride off of the output because it meant they didn't have to lift a finger. The people who actually do the work are naturally in the driver's seat.
This perspective is astonishingly historically ignorant, and ignores how "Open Source Software" was a deliberate political movement to simultaneously neuter the non-company-friendly goals of FOSS while simultaneously providing a competing (and politically distracting) movement that deliberately courted companies.
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.
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
> 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.
Nobody says that you will not have alternatives. What people are saying, is that if you're using those alternatives you won't be able to watch videos online, or access your bank account.
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.
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.)
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...
> 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
Yeah. I'm pretty sure it requires a very specific psychological profile to decide to work on such a user-hostile project while post-fact rationalizing that it's "for good".
All I can say is I'm not surprised that Poettering is involved in such a user-hostile attack on free computing.
P.S: I don't care about the downvotes, you shouldn't either.
Does this guy do anything that is user-friendly and is as per open source ethos of freedom and user control? In all this shit-show of Microsoft shoving AI down the throat of its users, I was happy to be firmly in the Linux camp for many many years. And along come these kind of people to shit on that parade too.
P.S: Upvoted you. I don't care about downvotes either.
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
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.
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. :)
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.
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.
Ah, good old remote attestation. Always works out brilliantly.
I have this fond memory of that Notary in Germany who did a remote attestation of me being with him in the same room, voting on a shareholder resolution.
While I was currently traveling on the other side of the planet.
This great concept that totally will not blow up the planet has been proudly brought to you by Ze Germans.
No matter what your intentions are: It WILL be abused and it WILL blow up. Stop this and do something useful.
[While systemd had been a nightmare for years, these days its actually pretty good, especially if you disable the "oh, and it can ALSO create perfect eggs benedict and make you a virgin again while booting up the system!" part of it. So, no bad feelings here. Also, I am German. Also: Insert list of history books here.]
What is the endgame here? Obviously "heightened security" in some kind of sense, but to what end and what mechanisms? What is the scope of the work? Is this work meant to secure forges and upstream development processes via more rigid identity verification, or package manager and userspace-level runtime restrictions like code signing? Will there be a push to integrate this work into distributions, organizations, or the kernel itself? Is hardware within the scope of this work, and to what degree?
The website itself is rather vague in its stated goals and mechanisms.
Personally for me this is interesting because there needs to be a way where a hardware token providing an identity should interact with a device and software combination which would ensure no tampering between the user who owns the identity and the end result of computing is.
A concrete example of that is electronic ballots, which is a topic I often bump heads with the rest of HN about, where a hardware identity token (an electronic ID provided by the state) can be used to participate in official ballots, while both the citizen and the state can have some assurance that there was nothing interceding between them in a malicious way.
- You're just moving your trust elsewhere, this time to a private corporation (whoever makes the CPU / TPM / other "trusted" component).
- This doesn't guarantee voter anonymity the way paper ballots do. Considering the analog hole and the complexity of computers, I can think of a billion ways a motivated and resourceful Mallory could to connect someone to their ballot.
> This doesn't guarantee voter anonymity the way paper ballots do.
You're saying that with a lot of assurance, but in my opinion that's still to be debated. We can build something that will keep at least a degree of separation between the identity that points to a specific individual and the identity that casts the ballot.
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.
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.
Entities other than me being able to control what runs on the device I physically posses is absolutely not acceptable in any way. Screw your clients, screw you shareholders and screw you.
Assuming you're using systemd, you already gave up control over your system. The road to hell was already paved. Now, you would have to go out of your way to retain control.
In the great scheme of things, this period where systemd was intentionally designed and developed and funded to hurt your autonomy but seemed temporarily innocuous will be a rounding error.
Nah man, yo are FUDing. systemd might have some poor design choices and arrogant maintainers, but at least I can drop it at any time and my bank wouldn't freak out about it. This one… It's a whole another level.
I don't think Mr Pottering was brought by accident, maybe his decade of contribution making sure systemd services can be manipulated by a supervisor (in the case of wsl and ms) is a valuable asset.
Systemd don't even need to change much to become the devil itself, it just have to upstream merge changes already consolidated in the past 5 years or so...
But logically it's safe because for this to become a problem systemd would have to be adopted by the majority of distributions and its maintainers would have to concede to the pressure of big corps and such...oh, wait
AFAIU (I haven't looked much into it) shim basically exists so that MS signs the shim once (or only a few times when updated), which has the distro public key embedded, which does further verification of the chain (bootloader/kernel) which gets updated more frequently.
That's basically my understanding too. But since you can still boot any shim-supported distro, Secure Boot + shim practically gains you nothing. An adversary can simply boot their own own copy of shim with whatever OS they like.
I don't know all the ins and outs, but because of the Machine Owner Key (MOK) mechanism in shim, it should be possible to boot arbitrary OSes without MS signing anything.
Your step of removing the MS keys works of course :) Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS. Also I think that firmware updates can be problematic?
> Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS
Yea, I bricked a Gigabyte board and still haven't been able to fix it. I just replaced it with an Asrock board and that has settings for what to do with option-rom when secureboot is enabled (always execute, always deny, allow execute, defer execute, deny execute and query user) and I have no clue what half of them specifically do (like, does "allow execute" only execute if a matching key exists and doesn't execute if it doesn't? and what is the difference between "always deny" and "deny execute"? and defer to when??). But I just set it to always execute and my problem is solved.
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.
"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."
See Android; or, where you no longer own your device, and if the company decides, you no longer own your data or access to it.
And if Linux$oft suddenly decides every user's system needs a backdoor or that every system mus automatically phone home with your entire browsing data, then, well, too bad, so sad of course!
I mentioned it somewhere else in the thread, and btw, I'm not affiliated with the company, this is just my charitable interpretation of their intentions: this is not for requiring _every_ consumer linux device to have attestation, but for specific devices that are needed for niche purposes to have a method to use an open OS stack while being capable of attestation.
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.
I agree with you - but considering what they want to implement and what it can be used for there are probably investors that might not want to be outed (this early). Kinda paranoid I admit, but history has shown that stuff like this WILL be misused.
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.
Remote attestation requires a great deal of trust... I know this comment is likely to be down-voted, but I can't think of a Lennart Poettering project that didn't try to extend, centralize, and conglomerate Linux with disastrous results in the short term; and less innovation, flexibility, and functionality in the long term. Trading the strength of Unix systems for goal of making them more "Microsoft" like.
Remote attestation requires a great deal of trust, and I simply don't have it when it comes to this leadership team.
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.
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.
> If you try to install a different operating system, your computer will not boot.
That does not follow. That would only very specifically happen when all of these are true:
1. Secure Boot cannot be disabled
2. You cannot provision your own Secure Boot keys
3. Your desired operating system is not signed by the computer's trusted Secure Boot keys
"Starting in a verified state and stay[ing] trusted over time" sounds more like using measured boot. Which is basically its own thing and most certainly does not preclude booting whatever OS you choose.
Although if your comment was meant in a cynical way rather than approaching things technically, than I don't think my reply helps much.
Why on earth would somebody make a company with one of the the most reviled programmers on earth? Everyone knows that everything he touches turns to shit.
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?
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.
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.
I had a situation like that with an undocumented behavior and systemd-tmpfiles. I wanted it to clean up a directory in /var/tmp/ occasionally. The automation using that directory kept breaking, however, because instead of either finding a whole intact git repo to update or a deleted repo, it instead found only a scattering of files that were root-owned with read-only permissions. There was yet another undocumented feature in systemd-tmpfiles where it would ignore root-owned, read-only files regardless of explicit configuration telling it to clean up the contents of those directories. Eventually this feature was quietly removed:
That was far from the only time that the systemd developers decided to just break norms or do weird things because they felt like it, and then poorly communicate that change. Change itself is fine, it's how we progress. But part of that arrogance that you mentioned was always framing people who didn't like capricious or poorly communicated changes as being against progress, and that's always been the most annoying part of the whole thing.
Speaking of systemd-tmpfiles, wasn't there an issue where asking it to clean all temp files would also rm -rf /home and this was closed as wontfix, intended behavior?
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?
Your distribution has configured your GDM or Getty to have some dependency on something that ultimately waits on dhcpcd/network-online.target.
It’s not really the fault of systemd; it just enables new possibilities that were previously difficult/impossible and now the usage of said possibilities is surfacing problems.
It is the fault of systemd that there's no interactive control.
On other inits, I can hit ctrl-C to break out of a poorly configured setup. Yes, it's more difficult when there's potentially parallelism. But systemd is not uniformly better than everything else when it lacks interactivity.
And it might not be better than everything else if common distributions set it up wrong because it's difficult to set it up right. If we're willing to discount problems related to one init system because the distribution is holding it wrong, then why don't we blame problems with other init systems on distributions or applications, too? There's no need to restart crashing applications if applications don't crash, etc.
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.
After over a decade of Debian, when I upgraded my PC, I tried every big systemd-based distro, including opensuse, which I wholly loathed. I finally decided on Void and feel at home as I did 20+ years ago when I began.
There are serious problems with the systemd paradigm, most of which I couldn't argue for or against. But at least in Void, I can remove network-manger altogether, use cron as I always have, and generally remain free to do as I please until eventually every package there is has systemd dependencies which seems frightfully plausible at this pace.
Void is as good as I could have wanted. If that ever goes, I guess it's either BSD or a cave somewhere.
I'm glad to see the terse questions here. They're well warranted.
Not stopping. Just clashing with that and a hundred other things that I never wanted managed by one guy. Systemd.timer, systemd.service, yes, trivial, but I don't catalog every thing that bothers me about systemd - I just stay away from it. There are plenty of better examples. So where ever I wrote 'stop', it should read hinder.
systemd parses your crontab and runs the jobs inside on its own terms
of course you can run Cron as well and run all your jobs twice in two different ways, but that's only pedantically possible as it's a completely useless way to do things.
> Void is as good as I could have wanted. If that ever goes, I guess it's either BSD or a cave somewhere.
If systemd-less Linux ever go, there are indeed still the BSDs. But I thought long and hard about this and already did some testing: I used to run Xen back in the early hardware-virt days and nowadays I run Proxmox (still, sadly, systemd-based).
An hypervisor with a VM and GPU passthrough to the VM is at least something too: it's going to be a long long while before people who want to take our ability to control our machines will be able to prevent us from running a minimal hypervisor and then the "real" OS in a VM controlled by the hypervisor.
I did GPU passthrough tests and everything works just fine: be it Linux guests (which I use) or Windows guests (which I don't use).
My "path" to dodge the cave you're talking about is going to involved an hypervisor (atm I'm looking at the FreeBSD's bhyve hypervisor) and then a VM running systemd-less Linux.
And seen that, today, we can run just about every old system under the sun in a VM, I take we'll all be long dead before evil people manage to prevent us from running the Linux we want, the way we want.
You're not alone. And we're not alone.
I simply cannot stand the insufferable arrogance of Agent Poettering. Especially not seen the kitchen sink that systemd is (systemd ain't exactly a homerun and many are realizing that fact now).
Gentoo doesn't "exist" because it is necessary to have an alternative to systemd. Gentoo is simply about choice and works with both openrc and systemd. It supported other inits to some degree as well im the past.
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.
Quadlet actually solves this. It's the newer way to define containers for systemd and handles the rootless user case properly. I migrated my services to it recently and it's much more robust than the old generate scripts.
Could you give an example system-level quadlet that accepts connections on a low port, like 80, but runs the actual container as a non-root user (and plays nice with systemd, no force kill after timeout to stop, no reporting as failed for a successful stop)?
My understanding is quadlet does not solve this, and my options are calling "systemctl --user" or "--userns auto". I would love to be wrong here.
As an alternative solution to the sibling comment, I do run everything rootless in systemd --user so my services don't have access to privileged ports, and use firewall rules to redirect the external interface low ports, to the local high ports (that sounds annoying but in practice I only redirect a single port - 443 - to traefik and the use it to route to the right container service depending on domain)
I solved the port 80 issue by adding AmbientCapabilities=CAP_NET_BIND_SERVICE to the Service section of the unit file. That lets you bind privileged ports while still defining a User= line to run non-root. The lifecycle management seems solid in my experience, no force kills required.
Quadlet are great but running podman via systemd as a non root user worked perfectly well before quadlets and I have no idea what your parent is talking about (I'm currently in the process of converting my home services from rootless podman over systemd to quadlet)
Fair, it worked, but podman generate systemd is deprecated now. I found the generated unit files pretty brittle to maintain compared to just having a declarative config that handles the lifecycle.
I agree 100%, I was stuck without quadlet in previous Debian stable so I had to work with systemd generate, but quadlets are undoubtedly better, and I was looking forward to upgrade Debian just for that, and now that I did, I'm really happy to migrate. Especially custom container image management is so much smoother.
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.
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.
All vague hand waving at this point and not much to talk about. We'll have to wait and see what they deliver, how it works and the business model to judge how useful it will be.
What might you call a sort of Dunbar's number that counts not social links, but rather the number of things to which a person must actively refuse consent to?
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.
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.
I might be behind on the latest counter-counter-counter-measures, but I know some of the leading AC solutions are already using IOMMU to wedge a firewall between passive DMA sniffers and the game processes memory.
> resolve the Linux gaming vs. anti-cheat stalemate
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?
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.
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.
Propaganda begins with reframing. What russia is waging is not a war, it's a special military operation. War is peace. Data on Windows is secure. Linux's security is far behind.
What are you talking about? This has nothing to do with general purpose computing and everything to do with allowing you to authenticate the parts of the Linux boot process that must by necessity be left unencrypted in order to actually boot your computer. This is putting SecureBoot and the TPM to work for your benefit.
It's not propaganda in any sense, it's recognizing that Linux is behind the state of the art compared to Windows/macOS when it comes to preventing tampering with your OS install. It's not saying you should use Windows, it's saying we should improve the Linux boot process to be a tight security-wise as the Windows boot process along with a long explanation of how we get there.
Secure boot is initialized by the first person who physically touches the computer and wants to initialize it. Guess who that is? Hint: it's not the final owner.
It's only secure from evil maker attacks if it can be wiped and reinitialised at any time.
You seem to be under the impression that you cannot reset your Secure Boot to setup mode. You can in the UEFI, doing so wipes any enrolled keys. This, of course assumes you trust the UEFI (and hardware) vendors. But if you don't, you have much bigger problems anyway.
Is it possible someone will eventually build a system that doesn't allow this? Yes. Is this influenced in any way by features of Linux software? No.
It is certainly influenced by the features of Linux software. If Linux does not support this then this preserves a platform as an escape route where this is not possible and this substantially reduces the incentive to provide certain content and services (!) only when this is enabled.
Yes you. The parts being expanded upon happen after the shim is authenticated by SecureBoot and are fully in your control. The scary part has already happened, Linux distros support SecureBoot right now and have for a while. Right now the current state of the Linux boot process is all the downsides (in your view) of SecureBoot with none of the upsides because very little is authenticated after that.
> we should improve the Linux boot process to be a tight security-wise as the Windows
I hope this never happens. I really want my data secure and I do have something to hide. So, no Microsoft keys on my computer and only I will decide what kind of software I get to run.
So to I guess spite Microsoft or something you're going to make your data less secure?
Turning off SecureBoot only means any rando can decide what software runs on your device and install a bootkit. Not authenticating the rest of the boot process as outlined here (what Microsoft calls Trusted Boot) only means that randos can tamper with your OS using the bits that can't be encrypted.
> Turning off SecureBoot only means any rando can decide what software runs on your device
I see it as exactly the opposite: turning SecureBoot on means someone else can and will decide what software runs on my device.
> spite Microsoft or something you're going to make your data less secure
We all know very well Microsoft's track record with security and with data protection measures and practice. Trusting Microsoft is... irrational, let's put it that way.
Considering that (for example) your data on ChromeOS is automatically copied to a server run by Google, who are legally compelled to provide a copy to the government when subject to a FISA order, it is unclear what Poettering's threat model is here. Handwringing about secure boot is ludicrous when somebody already has a remote backdoor, which all of the cited operating systems do. Frankly, the assertion of such a naked counterfactual says a lot more about Poettering than it does about Linux security.
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.
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?
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.
I don't like few pieces and Mr. Lennarts attitude to some bugs/obvious flaws, but by far much better than old sysv or really any alternative we have.
Doing complex flows like "run app to load keys from remote server to unlock encrypted partition" is far easier under systemd and it have dependency system robust enough to trigger that mount automatically if app needing it starts
There are genuine positive applications for remote attestation. E.g., if you maintain a set of servers, you can verify that it runs the software it should be running (the software is not compromised). Or if you are running something similar to Apple's Private Compute Cloud to run models, users can verify that it is running the privacy-preserving image that it is claiming to be running.
There are also bad forms of remote attestation (like Google's variant that helps them let banks block you if you are running an alt-os). Those suck and should be rejected.
> There are genuine positive applications for remote attestation
No doubt. Fully agree with you on that. However Intel ME will make sure no system is truly secure and server vendors do add their mandatory own backdoors on top of that (iLO for HP, etc).
Having said that, we must face the reality: this is not being built for you to secure your servers.
> Trusted boot is literally a form of DRM. A different one than remote attestation.
No, it's not. (And for that matter, neither is remote attestation)
You're conflating the technology with the use.
I believe that you have only thought about these technologies as they pertain to DRM, now I'm here to tell you there are other valid use cases.
Or maybe your definition of "DRM" is so broad that it includes me setting up my own trusted boot chain on my own hardware? I don't really think that's a productive definition.
there are no other things. The entire point of remote attestation is to manage(i.e. take away) rights of user that runs it, unless you own entire chain, which you do not on any customer device
> Interesting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source?
So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.
> So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.
Would love to hear more of your thoughts on how the users of the device I worked on had their freedom restricted!
I guess my company, the user of the device that I worked on, was being harmed by my company, the creator of the device that I worked on. It's too bad that my company chose to restrict the user's freedom in this way.
Who cares if the application of the device was an industrial control scenario where errors are practically guaranteed to result in the loss of human life, and as a result are incredibly high value targets ala Stuxnet.
No, the users rights to run any code trumps everything! Commercial device or not, ever sold outside of the company or not, terrorist firmware update or not - this right shall not be infringed.
I now recognize I have committed a great sin, and hope you will forgive me.
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.
Buddy, if I want encryption of my own I've got secure boot, LUKS, GPG, etc. With all of those, why would I need or even want remote attestation? The purpose of that is to assure corporations that their code is running on my computer without me being able to modify it. It's for DRM.
I am fairly confident that this company is going to assure corporations that their own code is running on their own computers (ie - to secure datacenter workloads), to allow _you_ (or auditors) to assure that only _your_ asserted code is also running on their rented computers (to secure cloud workloads), or to assure that the code running on _their_ computers is what they say it is, which is actually pretty cool since it lets you use Somebody Else's Computer with some assurance that they aren't spying on you (see: Apple Private Cloud Compute). Maybe they will also try to use this to assert "deep" embedded devices which already lock the user out, although even this seems less likely given that these devices frequently already have such systems in place.
IMO it's pretty clear that this is a server play because the only place where Linux has enough of a foothold to make client / end-user attestation financially interesting is Android, where it already exists. And to me the server play actually gives me more capabilities than I had: it lets me run my code on cloud provided machines and/or use cloud services with some level of assurance that the provider hasn't backdoored me and my systems haven't been compromised.
How can you be "pretty sure" they're going to develop precisely the technology needed to implement DRM but also will never use or allow it to be used by anybody but the lawful owners of the hardware? You can't.
It's like designing new kinds of nerve gas, "quite sure" that it will only ever be in the hands of good guys who aren't going to hurt people with it. That's powerful naïveté. Once you make it, you can't control who has it and what they use it for. There's no take-backsies, that's why it should never be created in the first place.
The technology needed to implement DRM has been there for 20+ years and has already evolved in the space where it makes sense from an "evil" standpoint (if you're on that particular side of the fence - Android client attestation), so someone implementing the flip side that might actually be useful doesn't particularly bother me. I remember the 1990s "cryptography is the weapon of evil" arguments too - it's funny how the tables have turned, but I still believe that in general these useful technologies can help people overall.
The technology already exists and also there is unmet industrial market demand for the technology. Incoherent. If it already exists as you say, then Lennart should fuck off and find something else to make.
> It's like designing new kinds of nerve gas, "quite sure" that it will only ever be in the hands of good guys who aren't going to hurt people with it. That's powerful naïveté. Once you make it, you can't control who has it and what they use it for. There's no take-backsies, that's why it should never be created in the first place.
Interesting choice of analogy, to compare something with the singular purpose to destroy biological entities, to a computing technology that enforces what code is run.
Can you not see there might be positive, non-destructive applications of the latter? Are you the type of person that argues cars shouldn't exist due to their negative impacts while ignoring all the positives?
I see the use case for servers targeted by malicious actors. A penetration test on an hardened system with secure boot and binary verification would be much harder.
For individuals, IMO the risk mostly come from software they want to run (install script or supply chain attack). So if the end user is in control of what gets signed, I don't see much benefit. Unless you force users to use an app store...
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.
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.
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?
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.
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.
> we will never enforce using any of these features in systemd itself. It will always be up to the distro
So, plausible deniability. It's not the systemd project, it's the distro.
> I certainly don't think distributions like Fedora or Debian will ever go in that direction.
In the past they made decisions that we can call unexpected. I believe that in the short term future they won't but in say ten years? I'm not sure. The technology (created by Amutable?) will be mature by that time and ready to close Linux down.
> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle
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.
> 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?
Why are you buying hardware that Microsoft controls if you're concerned about this?
Also, I know. A few of my colleagues run {open, free, dragonfly}BSD as their daily drivers for more than two decades. Also, we have BSD based systems at a couple of places.
However, as a user of almost all mainstream OSes (at the same time, for different reasons), and planning to include OpenBSD to that roster (taking care of a fleet takes time), I'd love to everyone select the correct tool for their applications and don't throw stones at people who doesn't act like them.
Please remember that we all sit in houses made of glass before throwing things to others.
Oh, also please don't make assumptions about people you don't know.
You could describe Richard Stallman as someone who refuses to use proprietary software because he sees using it as becoming complicit--however indirectly--in a technology ecosystem that violates the values he’s committed to.
"Just don't use X" is in fact a very engaged and principled response. Try again.
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.
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.
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.
“ensure that things are as they are expected to be” according to who, and for who's benefit? Certainly not the person sitting in front of the computer.
The system owner. Usually that is the same entity that owns the secure boot keys, which can be the person that bought a device or another person if the buyer decides to delegate that responsibility (whether knowingly or unknowingly).
In my case I am talking about myself. I prefer to actually know what is running on my systems and ensure that they are as I expect them to be and not that they may have been modified unbeknownst to me.
I don't think this is right. Usually, the entity that owns secure boot keys is a large tech corporation which paid to install their keys on all new computers.
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.
Trusted computing and remote attestation is like two people who want to have sex requiring clean STD tests first. Either party can refuse and thus no sex will happen. A bank trusting a random rooted smartphone is like having sex with a prostitute with no condom. The anti-attestation position is essentially "I have a right to connect to your service with an unverified system, and refusing me is oppression." Translate that to the STD context and it sounds absurd - "I have a right to have sex with you without testing, and requiring tests violates my bodily autonomy."
You're free to root your phone. You're free to run whatever you want. You're just not entitled to have third parties trust that device with their systems and money. Same as you're free to decline STD testing - you just don't get to then demand unprotected sex from partners who require it.
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?
"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?"
Because there are an infinite ways for a computer to be insecure and very few ways for it to be secure.
Checks were a form of attestation because they contained security features that banks would verify.
Would YOU be willing to use a bank that refused to use TLS? I didn't think so. How is you refusing to accept remote attestation and the bank refusing to connect to you any different?
So both consent to sex and now one thinks they're entitled to marriage. That's where this inevitably leads, user/customer lock-in and control.
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.
"It's going to be every god damned thing on the internet. Why? Because why the hell not"
This is not a persuasive argument.
You are also ignoring the fact that YOU can use remote attestation to verify remote computers are running what they say they are.
"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."
You actually sound like you are having a nervous breakdown. Perhaps you should take a vacation.
You are trying to portrait it as an exchange between equal parties which it isn't. I am totally entitled not to have to use a thrid-party-controlled device to access government services. Or my bank account.
remote attestation is just fancy digital signatures with hardware protected secret keys. Are you freaking out about digital signatures used anywhere else?
It absolutely does. Emphasis on use. The last thing I need is my bank requiring me to use a Poettering-certified distribution because anything else is "insecure".
You are acting very entitled thinking you can dictate the conditions under which you can connect to other people's computers. This is a "it takes two to tango" situation. I'm sure YOU would refuse to connect to any bank that refuses to use TLS.
Can it sets terms on my religious and political views? I'm not speaking about race and sex, you cannot choose them (ok, sex you could in some jurisdictions, and there is difference between sex and gender, please, don't be nitpicky here), but about things I can choose same as I can choose my hardware and software to run.
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.
You DO understand you can own more than one phone, right? Just use one that isn't rooted as a dedicated banking device and the rooted phone for whatever else you need. You are making life far too hard.
It is actually very easy to use VMs for the non attesting machine.
Would YOU be willing to use a bank that refused to use TLS? I didn't think so. How is you refusing to accept remote attestation and the bank refusing to connect to you any different?
Frankly this disgusts me. While there are technically user-empowering ways this can be used, by far the most prevalent use will be to lock users/customers out of true ownership of their own devices.
Device attestation fails? No streaming video or audio for you (you obvious pirate!).
Device attestation fails? No online gaming for you (you obvious cheater!).
Device attestation fails? No banking for you (you obvious fraudster!).
Device attestation fails? No internet access for you (you obvious dissident!).
Sure, there are some good uses of this, and those good uses will happen, but this sort of tech will be overwhelmingly used for bad.
Remote attestation only works because your CPU's secure enclave has a private key burned-in (fused) into it at the factory. It is then provisioned with a digital certificate for its public key by the manufacturer.
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.
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?
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.
Are you guys hiring? I can emulate a grim smile and have no problem being diabolical if the pay is decent so maybe I am a good fit?
I can also pet goats
I'm not seeing any big problems with the portraits.
Having said that, should this company not be successful, Mr Zbyszek Jędrzejewski-Szmek has potentially a glowing career as an artists' model. Think Rembrandt sketches.
I look forward to something like ChromeOS that you can just install on any old refurbished laptop. But I think the money is in servers.
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.
So much negativity in this thread. I actually think this could be useful, because tamper-proof computer systems are useful to prevent evil maid attacks. Especially in the age of Pegasus and other spyware, we should also take physical attack vectors into account.
I can relate to people being rather hostile to the idea of boot verification, because this is a process that is really low level and also something that we as computer experts rarely interact with more deeply. The most challenging part of installing a Linux system is always installing the boot loader, potentially setting up an UEFI partition. These are things that I don't do everyday and that I don't have deep knowledge in. And if things go wrong, then it is extra hard to fix things. Secure boot makes it even harder to understand what is going on. There is a general lack of knowledge of what is happening behind the scenes and it is really hard to learn about it. I feel that the people behind this project should really keep XKCD 2501 in mind when talking to their fellow computer experts.
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.
Hmph, AFAIK systemd has been struggling with TPM stuff for a while (much longer than I anticipated). It’s kinda understandable that the founder of systemd is joining this attestation business, because attestation ultimately requires far more than a stable OS platform plus an attestation module.
A reliably attestable system has to nail the entire boot chain: BIOS/firmware, bootloader, kernel/initramfs pairs, the `init` process, and the system configuration. Flip a single bit anywhere along the process, and your equipment is now a brick.
Getting all of this right requires deep system knowledge, plus a lot of hair-pulling adjustment, assuming if you still have hair left.
I think this part of Linux has been underrated. TPM is a powerful platform that is universally available, and Linux is the perfect OS to fully utilize it. The need for trust in digital realm will only increase. Who knows, it may even integrate with cryptocurrency or even social platforms. I really wish them a good luck.
I can see like a 100 ways this can make computing worse for 99% people and like 1-2 scenarios where it might actually be useful.
Like if the politicians pushing for chat control/on device scanning of data come knocking again and actually go through (they can try infinitely) tech like this will really be "useful". Oops your device cannot produce a valid attestation, no internet for you.
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.
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.
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.
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
> 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.
> 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.
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.
> it will be used for movies, government services, banks
I really, really don't think these entities care enough about desktop Linux. I'd be way more worried about some kind of Windows web-based attestation appearing. If that happens I really do think there's a bit of an alarm to sound, because this will make using desktop Linux inconvenient in the way attestation has made using alternate Android ROMs inconvenient.
> Because you are obviously a hacker, why else would anyone want to compile and run programs.
People buy computers to run programs, it doesn't behoove anyone to prevent this. These things are driven by economics, not some weird arbitrary drive towards evil. Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
> 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.
Why does everyone land on this complete non sequitur? It's not the flip of a switch, that's not how UEFI Secure Boot works to start with and even then, UEFI Secure Boot is not the root of trust on x86.
This was indeed the big "Free Software" vs UEFI "Secure" Boot conspiracy theory 20+ years ago, but it didn't make sense then, doesn't make sense now, and sure enough, hasn't come to pass. First off, Microsoft aren't Intel, who own the root of trust on Intel CPUs. Second off, again, there's no incentive to do this. CPUs are a competitive market and people buy CPUs to run code. There is no reason for Intel to suddenly decide to exclusively enforce firmware verification in a way that only chained down to one vendor's keys; they're in the business of selling CPUs to people who want to run things. Also, the notion that some CPU vendor will suddenly lock down firmware keys has nothing to do with the article in question or the notion of an immutable or attestable Linux.
Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
Where I live in Europe, Fairphones are becoming fairly popular (as in, I encounter non-tech people using Fairphones). A subset of those users run /e/OS (anti-Google/big tech sentiment is growing pretty strong). This is increasingly becoming a risk for Google, because if /e/OS takes off big time in Europe, it would be easy to support a European app store besides Google Play and F-Droid (which the /e/OS App Lounge already support), leading to a loss of 30% on app spending.
Google will abuse their remote attestation implementation to shut out competitors. If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
> If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
Google actually "gave" customers the choice here, although I agree with you that it's crappy and there was almost surely some monopolistic intent -
There _is_ a standard implementation, the Hardware Attestation API. Unfortunately it is annoying to use in a practical way; it requires a fair amount of PKI-wrangling (although there's a Google library for it) and more importantly to allow non-Google trust chains but still enforce boot security, app developers need all of the verifiedBootKey hashes for the non-Google trust chains they want to trust. This makes sense, but unfortunately becomes a maintenance problem and turns app developers off of this.
So, app developers choose the Play Integrity API instead because it's easy, even though they get the side effect that they verify that the device is a licensed Google Play device rather than just a "clean" Android device.
All this is to say that if something like /e/OS were to actually take off, app developers could upgrade their apps to support attestation with the Hardware Attestation API with some extra effort - Google aren't really preventing them and the feature is there.
Anyway, going all the way back to the original story again, I still can't buy into the hand-wringing. A verified, attestable Linux on the server (or for stuff like forward deployed devices) seems quite cool and useful to me, and while I respect the issues with client attestation and the negative effect it can have on hardware ownership, I both don't see it as a practical outcome from this company and don't see it as a practical threat on the desktop at this time.
> 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.
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 don't see how this relates in any way to Amutable and it has been a "concern" for 20+ years (which has never come to pass). How do you think this relates at all?
Before this point in time, Linux never supported being an immutable image. Neither filesystems, nor the mechanism to lock it down was there. The best you could do was, TiVoization, but that would be too obvious and won't fly.
Now we have immutable distributions (SuSE, Fedora, NixOS). We have the infrastructure for attestation (systemd's UKI, image based boot, and other immutability features), TPMs and controversially uutils (Which is MIT licensed and has the stated goal to replace all GNU userspace).
You can build an immutable and adversarial userspace where you don't have to share the source, and require every boot and application call to attest. The theoretical thickness of the wall is both much greater and this theoretical state is much easier to achieve.
20 years ago the only barrier was booting. After that everything was free. Now it's possible to boot into a prison where your every ls and cd command can be attested.
> Before this point in time, Linux never supported being an immutable image.
What? As just one example, dm-verity was merged into the mainline kernel 13 years ago. I built immutable, verified Linux systems at least ten years ago, and it was considered old hat by the time I got there.
> The best you could do was, TiVoization, but that would be too obvious and won't fly.
What does this even mean? "TiVoization" is the slang for "you get a device that runs Linux, you get the GPL sources, but you can't flash your own image on the device because you don't own the keys." This is the exact same problem then as it was now and just as "obvious?"
I understand the fears that come from client attestation (certainly, the way it has been used on Android has been majorly detrimental to non-Google ROMs), but, to the Android point, the groundwork has always been there.
I'd be very annoyed if someone showed up and said "we're making a Linux-based browser attestation system that your bank is going to partner on," but nobody has even gone this direction on Windows yet.
> Oh, Rust is memory safe. Good luck finding holes.
I break secure boot systems for a living and I'd say _maybe_ half of the bugs I find relate to memory safety in a way Rust would fix. A lot of systems already use tools which provide very similar safety guarantees to Rust for single threaded code. Systems are definitely getting more secure and I do worry about impenetrable fortresses appearing in the near future, but making this argument kind of undermines credibility in this space IMO.
Yes, I reference Android client attestation in my comments in this thread frequently. I actually see this company as likely to be the flip side of the “bad” client attestation coin; server attestation actually provides a lot of nice properties to end users and providers who wish to provide secure solutions with very limited user downside.
It won't remain "server" attestation. It will become "client" attestation, with the end result that you won't own your own machine anymore, you'll just be paying for a client device upon which you won't control the hardware or software anymore. See any mobile phone at all, anymore.
I don’t see anyone investing in this for general purpose desktop Linux in the state desktop Linux exists today; the harbinger of the Desktop Linux Apocalypse would be web-based Windows attestation (just as Android attestation is eroding alt-OSes) which feels like a viable “threat” but thankfully doesn’t seem to be happening just yet.
I do think this approach might get used for client attestation in gaming, which I actually don’t mind; renting/non-owning a client that lets me play against non cheaters is a pretty good gaming outcome, and needing a secure configuration to run games seems like a fine trade for me (vs for example needing a secure desktop configuration to access my bank, which would be irksome).
The idea is that by protecting boot path you build a platform from which you can attest the content of the application. The goal here is usually that a cloud provider can say “this cryptographic material confirms that we are running the application you sent us and nothing else” or “the cloud application you logged in to matched the one that was audited 1:1 on disk.”
"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?
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.
Not if the end user is an operator of safety critical equipment, such as rail or pro audio or any of a number of industries where stability and reproducibility is essential to the product.
Ever seen a default ubuntu splash screen/wallpaper on a train, coffee machine, airport terminal kiosk, bus, or other big piece of slow moving, appliance-y thing?
That is why Ubuntu Core (and similar) exist. More secure, better update strategy, lower net cost. I don't agree with the licensing or pricing model, but there are perfectly good technical reasons to use it.
Appreciate the clarification, but this actually raises more questions than it answers.
A "robust path to revenue" plus a Linux-based OS and a strong emphasis on EU / German positioning immediately triggers some concern. We've seen this pattern before: wrap a commercially motivated control layer in the language of sovereignty, security, or European tech independence, and hope that policymakers, enterprises, and users don't look too closely at the tradeoffs.
Europe absolutely needs stronger participation in foundational tech, but that shouldn't mean recreating the same centralized trust and control models that already failed elsewhere, just with an EU flag on top. 'European sovereignty' is not inherently better if it still results in third-party gatekeepers deciding what hardware, kernels, or systems are "trusted."
Given Europe's history with regulation-heavy, vendor-driven solutions, it's fair to ask:
Who ultimately controls the trust roots?
Who decides policy when commercial or political pressure appears?
What happens when user interests diverge from business or state interests?
Linux succeeded precisely because it avoided these dynamics. Attestation mechanisms that are tightly coupled to revenue models and geopolitical branding risk undermining that success, regardless of whether the company is based in Silicon Valley or Berlin.
Hopefully this is genuinely about user-verifiable security and not another marketing-driven attempt to position control as sovereignty. Healthy skepticism seems warranted until the governance and trust model are made very explicit.
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?
This is not about the person being attacked, it's about what this kind of thing does to us as a community. It's not what the site is for, and destroys what it is for.
My comment was not a personal attack. But I can rephrase it if you want it more in the spirit of the guidelines. Here we go:
I'm interested in what Amutable is building, but I'm personally uneasy about Lennart Poettering being involved. This isn't about denying his technical ability or past impact. My concern is more about the social/maintenance dynamics that have repeatedly shown up around some of the projects he's led in the Linux ecosystem - highly centralizing designs, big changes quickly landing in core technology, and the kind of communication/governance style that at times left downstream maintainers and parts of the community feeling steamrolled rather than brought along. I've watched enough of those cycles to be wary when the same leadership style shows up again, especially in something that might become infrastructure people depend on.
To keep this constructive: for folks who've followed his work more closely than I have, do you think those past community frictions were mostly a function of the environment (big distro politics, legacy constraints, etc), or are they intrinsic to how he approaches projects? And for people evaluating Amutable today, what signals would you look for to distinguish "strong technical leadership" from "future maintenance and ecosystem headaches" ?
If anyone from the company is reading, I'd be genuinely reassured by specifics like:
- a clear governance/decision process (who can say "no", how major changes are reviewed)
- a commitment to compatibility and migration paths (not just "it's better, switch")
- transparent security and disclosure practices
- a plan for collaboration with downstream parties and competitors (standards, APIs, interop)
I realize this is partly subjective. I’m posting because I expect I'm not the only one weighing "technical upside" against "community cost," and I'd like to hear how others are thinking about it.
If you don't think that's a community opinion, it's at least an AI's opinion, since all I prompted it with was "rewrite my comment to follow the HN guidelines"
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.
People demonize attestation. They should keep in mind that far from enslaving users, attestation actually enables some interesting, user-beneficial software shapes that wouldn't be possible otherwise. Hear me out.
Imagine you're using a program hosted on some cloud service S. You send packets over the network; gears churn; you get some results back. What are the problems with such a service? You have no idea what S is doing with your data. You incur latency, transmission time, and complexity costs using S remotely. You pay, one way or another, for the infrastructure running S. You can't use S offline.
Now imagine instead of S running on somebody else's computer over a network, you run S on your computer instead. Now, you can interact with S with zero latency, don't have to pay for S's infrastructure, and you can supervise S's interaction with the outside world.
But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.
However --- if S's author could run S on your computer in such a way that he could prove you haven't tampered with S or haven't observed its secrets, he can let you run S on your computer without giving up control over S. Attestation, secure enclaves, and other technologies create ways to distribute software that otherwise wouldn't exist. How many things are in the cloud solely to enforce access control? What if they didn't have to be?
Sure, in this deployment model, just like in the cloud world, you wouldn't be able to run a custom S: but so what? You don't get to run your custom S either way, and this way, relative to cloud deployment, you get better performance and even a little bit more control.
Also, the same thing works in reverse. You get to run your code remotely in a such a way that you can trust its remote execution just as much as you can trust that code executing on your own machine. There are tons of applications for this capability that we're not even imagining because, since the dawn of time, we've equated locality with trust and can now, in principle, decouple the two.
Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.
> People demonize attestation. They should keep in mind that far from enslaving users, attestation actually enables some interesting, user-beneficial software shapes that wouldn't be possible otherwise. Hear me out.
But it won't be used like that. It will be used to take user freedoms out.
> But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.
That use case you're describing is already there and is currently being done with DRM, either in browser or in app itself.
You are right in the "it will make easier for app user to do it", and in theory it is still better option in video games than kernel anti-cheat. But it is still limiting user freedoms.
> Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.
Majority of the uses will be user-hostile things. Because those are only cases where someone will decide to fund it.
> Attestation, secure enclaves, and other technologies create ways to distribute software that otherwise wouldn't exist. How many things are in the cloud solely to enforce access control? What if they didn't have to be?
To be honest, mainly companies need that. personal users do not need that. And additionally companies are NOT restrained by governments not to exploit customers as much as possible.
So... i also see it as enslaving users. And tell me, for many private persons, where does this actually give them for PRIVATE persons, NOT companies a net benefit?
> This potential shouldn't prevent our inventing new kinds of tool.
Why do i see someone who wants to build an atomic bomb for shit and giggles using this argument, too? As hyperbole as my argument is, the argument given is not good here, as well.
The immutable linux people build tools, without building good tools which actually make it easier for private people at home to adapt a immutable linux to THEIR liking.
The atomic bomb is good example of what I'm talking about. The reason we haven't had a world war in 80 years is the atomic bomb. Far from being an instrument of misery, it's given us an age of unprecedented peace and prosperity. Plus, all the anti-nuclear activism in the world hasn't come one step closer to banishing nuclear weapons from the earth.
In my personal philosophy, it is never bad to develop a new technology.
I will put some trust into these people if they make this a pure nonprofit organization at the minimum. Building ON measures to ensure that this will not be pushed for the most obvious cases, which is to fight user freedom. This shouldn't be some afterthought.
"Trust us" is never a good idea with profit seeking founders. Especially ones who come from a culture that generally hates the hacker spirit and general computing.
You basically wrote a whole narrative of things that could be. But the team is not even willing to make promises as big as yours. Their answers were essentially just "trust us we're cool guys" and "don't worry, money will work out" wrapped in average PR speak.
I'm guessing you're referencing my comment, that isn't what I said.
> But the team is not even willing to make promises as big as yours.
Be honest, look at the comment threads for this announcement. Do you honestly think a promise alone would be sufficient to satisfy all of the clamouring voices?
No, people would (rightfully!) ask for more and more proof -- the best proof is going to be to continue building what we are building and then you can judge it on its merits. There are lots of justifiable concerns people have in this area but most either don't really apply what we are building or are much larger social problems that we really are not in a position to affect.
I would also prefer to be to judged based my actions not on wild speculation about what I might theoretically do in the future.
Shall it be backdoorable like systemd-enabled distro nearly had a backdoorable SSH? For non-systemd distro weren't affected.
Why should we trust microsofties to produce something secure and non-backdoored?
And, lastly, why should Linux's security be tied to a private company? Oooh, but it's of course not about security: it's about things like DRM.
I hope Linus doesn't get blinded here: systemd managed to get PID 1 on many distros but they thankfully didn't manage, yet, to control the kernel. I hope this project ain't the final straw to finally meddle into the kernel.
Currently I'm doing:
Proxmox / systemd-less VMs / containers
But Promox is Debian based and Debian really drank too much of the systemd koolaid.
So my plan is:
FreeBSD / bhyve hypervisor / systemd-less Linux VMs / containers
And then I'll be, at long last, systemd-free again.
This project is an attack on general-purpose computing.
Cheating was solved before any of this rootkit level malware horseshit.
Community ran servers with community administration who actually cared about showing up and removing bad actors and cheaters.
Plenty of communities are still demonstrating this exact fact today.
Companies could 100% recreate this solution with fully hosted servers, with an actually staffed moderation department, but that slightly reduces profit margins so fuck you. Keep in mind community servers ran on donations most of the time. That's the level of profit they would lose.
Companies completely removed community servers as an option instead, because allowing you to run your own servers means you could possibly play the game with skins you haven't paid for!!! Oh no!!! Getting enjoyment without paying for it!!!
All software attempts at anti-cheat are impossible. Even fully attested consoles have had cheats and other ways of getting an advantage that you shouldn't have.
Cheating isn't defined by software. Cheating is a social problem that can only be solved socially. The status quo 20 years ago was better.
Everyday the world is becoming more polarized. Technology corporations gain ever more control over people's lives, telling people what they can do on their computers and phones, what they can talk about on social platforms, censoring what they please, wielding the threat of being cutoff from their data, their social circles on a whim. All over the world, in dictatorships and also in democratic countries, governments turn more fascist and more violent. They demonstrate that they can use technology to oppress their population, to hunt dissent and to efficiently spread propaganda.
In that world, authoring technology that enables this even more is either completely mad or evil. To me Linux is not a technological object, it is also a political statement. It is about choice, personal freedom, acceptance of risk. If you build software that actively intends to take this away from me to put it into the hands of economic interests and political actors then you deserve all the hate you can get.
> To me Linux is not a technological object, it is also a political statement. It is about choice, personal freedom ...
I use Linux since the Slackware day. Poettering is the worse thing that happened to the Linux ecosystem and, of course, he went on to work for Microsoft. Just to add a huge insult to the already painful injury.
This is not about security for the users. It's about control.
At least many in this thread are criticizing the project.
And, once again of course, it's from a private company.
Full of ex-Microsofties.
I don't know why anyone interested in hacking would cheer for this. But then maybe HN should be renamed "CN" (Corporate News) or "MN" (Microsoft News).
> Poettering is the worse thing that happened to the Linux ecosystem and, of course, he went on to work for Microsoft. Just to add a huge insult to the already painful injury.
agreed, and now he's planning on controlling what remains of your machine cryptographically!
Hi, Chris here, CEO @ Amutable. We are very excited about this. Happy to answer questions.
Well I was wondering when the war on general computing and computer ownership would be carried into the heart of the open source ecosystems.
Sure, there are sensible things that could be done with this. But given the background of the people involved, the fact that this is yet another clear profit-first gathering makes me incredibly pessimistic.
This pessimism is made worse by reading the answers of the founders here in this thread: typical corporate talk. And most importantly: preventing the very real dangers involved is clearly not a main goal, but is instead brushed off with empty platitudes like "I've been a FOSS guy my entire adult life...." instead of describing or considering actual preventive measures. And even if the claim was true, the founders had a real love for the hacker spirit, there is obviously nothing stopping them from selling to the usual suspects and golden parachute out.
I was really struggling to not make this comment just another snarky, sarcastic comment, but it is exhausting. It is exhausting to see the hatred some have for people just owning their hardware. So sorry, "don't worry, we're your friends" just doesn't cut it to come at this with a positive attitude.
The benefits are few, the potential to do a lot of harm is large. And the people involved clearly have the network and connections to make this an instrument of user-hostility.
I do sort of wonder if there’s room in my life for a small attested device. Like, I could actually see a little room for my bank to say “we don’t know what other programs are running on your device so we can’t actually take full responsibility for transactions that take place originated from your device,” and if I look at it from the bank’s point of view that doesn’t seem unreasonable.
Of course, we’ll see if anybody is actually engaging with this idea in good faith when it all gets rolled out. Because the bank has full end-to-end control over the device, authentication will be fully their responsibility and the (basically bullshit in the first place) excuse of “your identity was stolen,” will become not-a-thing.
Obviously I would not pay for such a device (and will always have a general purpose computer that runs my own software), but if the bank or Netflix want to send me a locked down terminal to act as a portal to their services, I guess I would be fine with using it to access (just) their services.
I suggested this as a possible solution in another HN thread a while back, but along the lines of "If a bank wants me to have a secure, locked down terminal to do business with them, then they should be the ones forking it over, not commanding control of my owned personal device."
It would quickly get out of hand if every online service started to do the same though. But, if remote device attestation continues to be pushed and we continue to have less and less control and ownership over our devices, I definitely see a world where I now carry two phones. One running something like GrapheneOS, connected to my own self-hosted services, and a separate "approved" phone to interact with public and essential services as they require crap like play integrity, etc.
But at the end of the day, I still fail see why this is even a need. Governments, banks, other entities have been providing services over the web for decades at this point with little issue. Why are we catering to tech illiteracy (by restricting ownership) instead of promoting tech education and encouraging people to both learn, and importantly, take responsibility for their own actions and the consequences of those actions.
"Someone fell for a scam and drained their bank account" isn't a valid reason to start locking down everyone's devices.
I was hoping banks would turn to using Yubikeys/U2F for authentication/transaction signing, and not these Draconian measures.
I remember my parents doing online banking authenticating with smart cards. Over 20 years ago. Today the same bank requires an iOS or Play Integrity device (for individuals at least. Their gated business banking are separate services and idk what they offer there).
This is not a question of missing tech.
> I suggested this as a possible solution in another HN thread a while back, but along the lines of "If a bank wants me to have a secure, locked down terminal to do business with them, then they should be the ones forking it over, not commanding control of my owned personal device."
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.
Yeah, to some extent I just wanted to think about where the boundary ought to be. I somewhat suspect the bank or Netflix won’t be willing to send me a device of theirs to act as their representative in my pocket. But it is basically the only time a reasonable person should consider using such a device. Anybody paying to buy Netflix or the bank a device is basically being scammed or ripped off.
Why should I need a separate device? Doesn't a hardware security token suffice? I wouldn't even mind bringing my own but my bank doesn't accept them last I checked. (Do any of them?)
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.
You shouldn't need a separate device, but we are quickly entering an era where a lot of banking (and other) apps will outright refuse to run or allow logins if it detects a rooted device, or play integrity fails.
In this way, the banks are asserting control over your device. It's beyond authentication, they are saying "If you have full control over your device, you cannot access our services."
I'll agree with you that they don't have a valid position, because I can just as easily open up a web browser on said rooted device and access just fine via the web, but how long until services move away from web interfaces in favor of apps instead to assert more control?
I have to use my phone to approve the web login to my account. My bank is working very hard to make sure that everyone uses the app for everything, including closing down offices and removing ATMs around the city.
A hardware token would not suffice. When you login with a hardware token it will generate some sort of token or cookie for further requests. This is where malware can steal that key and use it for whatever it wants. There is a benefit it knowing there is a high chance that the such a key is protected by the operating system's sandboxing technology. Without remote attestation you don't know if the sandbox is actually active or not.
On the contrary, a hardware token will suffice to thwart both phising and MitM which covers ~everything for all practical threat and liability models. What exactly is the concern here? A widespread worm that no one is yet aware of that's dumping people's bank accounts into crypto? It might make for a decent Hollywood plot but is pulling that off actually easier than attacking the bank directly?
Keep in mind that the businesses pushing this stuff still don't support U2F by and large. When I can go down in person to enroll a hardware token I might maybe consider listening to what they have to say on the subject. Maybe. (But probably not.)
Hypothetically on a fully controlled system you could prevent attacks like the sort of “hello this is Microsoft, we’ve identified a virus on your device, please download teamviewer and login to your bank account so we can clear it for you” type spam calls.
Or, hasn’t there been malware that periodically takes screenshots of the device? Or maybe that’s a Hollywood plot, I forget actually.
Keep in mind that a truly clueless user will most likely be running in a stock configuration. So long as that doesn't permit apps to tamper with one another (as is currently the case) there should be no issue. Google could even provide a toggle to officially root the phone and so long as flipping it wiped the device the problem would remain 99.9% solved because a scammer would be unable to pull the job off in one go.
By the time you reach the point that the user is doggedly following harmful step by step instructions over the course of multiple callbacks there is nothing short of a padded cell that can protect him from himself.
Unless you mean to suggest somehow screening such calls? A local LLM? Literal wiretapping via realtime upload to the cloud? If facing such a route society would likely be better off institutionalizing anyone victimized in such a manner.
> hasn’t there been malware that periodically takes screenshots of the device?
Yeah, it's called Recall and its baked into Windows as a "feature."
It's unfortunate because it's actually incredibly useful functionality. If only they hadn't packaged and marketed it in quite the way they did. If there was ever a feature that needed to be guaranteed local only, zero third party integration, zero first party analytics, encryption tied to a TPM that was it.
How does it solve MITM? You type your hardware token in and then an attacker uses it to send money out of your account.
>What exactly is the concern here?
Stealer malware. Or even RATs where attackers get notified when you open a sensitive app and they can take over after you have authenticated.
Could you please spell out the specifics of this scenario?
MitM via an evil (ie incorrect) domain name is prevented because U2F (and now webauthn or CTAP2) are origin bound.
RATs? On stock android? How does that work? And how are the things you describe not also threats for online banking via a browser? It's certainly not how the vast majority of attacks take place in the wild. Can you provide any examples of such an attack (ie malware as opposed to phishing) that was widespread? Otherwise I assume we're writing a script for Hollywood here.
Even then, a RAT could be trivially defeated by requiring a second one-off token authentication for any transaction that would move money around. I doubt there'd be much objection to such a policy. If people really hate it let them opt out below an amount of their choosing by signing a liability waiver.
>are origin bound.
This is assuming the user's device is not compromised.
>How does that work?
Priviledge escalation on an old OS version allows an attacker to get root access. Then with that they can bypass any sandboxing. Or they could get access to some android permission intended for system apps that they should not have access to and use that to do malicous things.
I don't closely follow malware outbreaks for android so I can't point to specific examples, but malware does exist.
So the attacker compromises the user's device ... and then sets up a MitM? This is making about as much sense as the typical Hollywood plot that involves computers so I guess that means we're on track.
> Priviledge escalation on an old OS version allows an attacker to get root access.
At which point hardware attestation accomplishes nothing. Running in an enclave might but attesting the OS image that was used to boot most certainly won't.
Many consumers use older devices. Any banking app is forced to support them or they will lose customers. There's no way around that. (It doesn't matter anyway because these sorts of attacks simply aren't commonplace.)
> but malware does exist.
I didn't ask for an example of malware. I asked you to point to an example of a widespread attack against secured accounts using malware as a vector. You have invented some utterly unrealistic scenario that simply isn't a concern in the real world for a consumer banking interaction.
You're describing the sort of high effort targeted attack utilizing one or more zero days that a high level government official might be subject to.
>At which point hardware attestation accomplishes nothing
Attestation could be used to say that the user is not using a secure version of the OS That has known vulnerabilities patched.
>Any banking app is forced to support them or they will lose customers.
Remote attestation is just one of the many signals used for detecting fraud.
>one or more zero days
Many phones are not on an OS getting security updates. Whether that be due to age or the vendor not distributing the security patches. Even using old exploits malware can work.
> with little issue
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.
The bank thing is a smoke screen.
This entire shit storm is 100% driven by the music, film, and tv industries, who are desperate to eke a few more millions in profit from the latest Marvel snoozefest (or whatever), and who tried to argue with a straight face that they were owed more than triple the entire global GDP [0].
These people are the enemy. They do not care about about computing freedom. They don't care about you or I at all. They only care about increasing profits via and they're using the threat of locking people out of Netflix via HDCP and TPM, in order to force remote attestation on everyone.
I don't know what the average age on HN is, but I came up in the 90s when "fuck corporations" and "information wants to be free" still formed a large part of the zeitgeist, and it's absolutely infuriating to see people like TFfounders actively building things that will measurably make things worse for everyone except the C-suite class. So much for "hacker spirit".
[0] https://globalnews.ca/news/11026906/music-industry-limewire-...
Also worth remembering that around 2010, the music and film industry associations of America were claiming entitlement to $50 billion dollars annually in piracy-related losses beyond what could be accounted for in direct lost revenue (which _might_ have been as much as 10 billion, or 1/6th of their claim):
https://youtu.be/GZadCj8O1-0
These guys pathologically have had a chip on their shoulder since Napster.
HN is for the kind of hacker who makes the next Uber or AirBNB. It's strongly aligned with the interests of corporate shareholders.
Yeah, as I am reading the landing page, the direction seems clear. It sucks, because as an individual there is not much one can do, and there is no consensus that it is a bad thing ( and even if there was, how to counter it ). Honestly, there are times I feel lucky to be as dumb as I am. At least I don't have the same responsibility for my output as people who create foundational tech and code.
> [T]he war on general computing and computer ownership [...] It is exhausting to see the hatred some have for people just owning their hardware.
The integrity of a system being verified/verifiable doesn't imply that the owner of the system doesn't get to control it.
This sort of e2e attestation seems really useful for enterprise or public infrastructure. Like, it'd be great to know that the ATMs or transit systems in my city had this level of system integrity.
You argument correctly points out that attestation tech can be used to restrict software freedom, but it also assumes that this company is actively pursuing those use cases. I don't think that is a given.
At the end of the day, as long as the owner of the hardware gets to control the keys, this seems like fantastic tech.
> You argument correctly points out that attestation tech can be used to restrict software freedom, but it also assumes that this company is actively pursuing those use cases. I don't think that is a given.
Once it's out there and normalized, the individual engineers don't get to control how it is used. They never do.
Unless Lennart Pottering uses remote attestation to verify who is attesting to whom.
System integrity also ends at the border of the system. The entire ecosystem of ATM skimmers demonstrates this-- the software and hardware are still 100% sanctioned, they're just hidden beneath a shim in the card slot and a stick-on keypad module.
I generally agree with the concept of "if you want me to use a pre-approved terminal, you supply it." I'd think this opens up a world of better possibilities. Right now, the app-centric bank/media company/whatever has to build apps that are compatible with 82 bazillion different devices, and then deal with the attestation tech support issues. Conversely, if they provide a custom terminal, it might only need to deal with a handful of devices, and they could design it to function optimally for the single use case.
> At the end of the day, as long as the owner of the hardware gets to control the keys, this seems like fantastic tech.
The problem is that there are powerful corporate and government interests who would love nothing more than to prevent users from controlling the keys for their own computers, and they can make their dream come true simply by passing a law.
It may be the case that certain users want to ensure that their computers are only running their code. But the same technologies can also used to ensure that their computers are only running someone else's code, locking users out from their own devices.
That's like saying we shouldn't build anything that can be used for good if it can also be used for evil.
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?
>if I want e2e attestation of the software stack on my own devices, isn't this a good thing for me?
The building blocks are already there for a sufficiently motivated user to build their own verified OS image. Google has been doing that with ChromeOS for years. The danger I see is that once there is a low-friction, turnkey solution for locking down general purpose systems, then the battle for control over users' devices reduces to control over the keys. That is much easier for well-heeled interests to dominate than outlawing Linux outright.
The status quo is a large population of unverified but fully user-configurable systems. While the ideal end state is a large population of verified and fully user-configurable systems, it is more likely that the tools for achieving that outcome will be co-opted by corporate and political interests to bend the population toward verified and un-configurable systems. That outcome would be far worse than the status quo.
Attestation tech is much more useful for evil than for good.
You want PCIe-6? Cool well that only runs on Asus G-series with AI, and is locked to attested devices because the performance is so high that bad code can literally destroy it. So for safety, we only run trusted drivers and because they must be signed, you have to use Redhat Premium at a monthly cost of $129. But you get automatic updates.
Do you want the control systems of the subway to get modified by a malicious actor? What about damn releases? Heat pumps in apartment buildings? Robotaxis? Payroll systems? Banks?
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.
It seems like we're doing pretty well without the baby. You sell it, you say we need it. Highly credible
My tinfoil hat theory is devices like HDDs will be locked and only work on "attested" systems that actively monitor the files. This will be pushed by the media industry to combat piracy. Then opened up for para-law enforcement like palantir.
Then gpu and cpu makers will hop on and lock their devices to promote paid Linux like redhat. Or offering "premium support" to unlock your gpu for Linux for a monthly fee.
They'll say "if you are a Linux enthusiast then go tinker with arm and risc on an SD card"
Remote attestation only works because your CPU's secure enclave has a private key burned-in (fused) into it at the factory. It is then provisioned with a digital certificate for its public key by the manufacturer.
Every time you perform an attestation the public key (and certificate) is divulged which makes it a unique identifier, and one that can be traced to the point of sale - and when buying a used device, a point of resale as the new owner can be linked to the old one.
They make an effort to increase privacy by using intermediaries to convert the identifier to an ephemeral one, and use the ephemeral identifier as the attestation key.
This does not change the fact that if the party you are attesting to gets together with the intermediary they will unmask you. If they log the attestations and the EK->AIK conversions, the database can be used to unmask you in the future.
Also note that nothing can prevent you from forging attestations if you source a private-public key pair and a valid certificate, either by extracting them from a compromised device or with help from an insider at the factory. DRM systems tend to be separate from the remote attestation ones but the principles are virtually identical. Some pirate content producers do their deeds with compromised DRM private keys.
I tend to buy such things with cash, in person.
People dislike cash for some strange reason, then complain about tracking. People also hand out their mobile number like candy. Same issue.
> People dislike cash for some strange reason
In my case it is because I would never have the right amount with me, in the right denominations. Google Pay always has this covered.
Also you need to remember to take one more thing with you, and refill it occasionally. As opposed to fuel, you do not know how much you will need when.
It can get lost or destroyed, and is not (usually) replaceable.
I am French, currently in the US. I need to change 100 USD in small denominations, I will need to go to the bank, and they will hopefully do that for me. Or not. Or not without some official paper from someone.
Ah yes, and I am in the US and the Euro is not an accepted currency here. So I need to take my 100 € to a bank and hope I can get 119.39 USD. In the right denominations.
What will I do with the 34.78 USD left when I am back home? I have a chest of money from all over the world. I showed it once to my kids when they were young, told a bit about the world and then forgot about it.
Money also weights quite a lot. And when it does not weights it gets lost or thrown away with some other papers. Except if they are neatly folded in a wallet, which I will forget.
I do not care about being traced when going to the supermarket. If I need to do untraceable stuff I will get money from teh ATM. Ah crap, they will trace me there.
So the only solution is to get my salary in cash, whihc is forbidden in France. Or take some small amounts from time to time. Which I will forget, and I have better things to do.
Cash sucks.
Sure, if we go cashless and terrible things happen (cyberwar, solar flare, software issues) then we are screwed. But either the situation unscrews itself, or we will have much, much, much bigger issues than money -- we will need to go full survival mode, apocalypse movies-style.
Anonymous-attestation protocols are well known in cryptography, and some are standardized: https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation
> Anonymous-attestation protocols are well known in cryptography, and some are standardized: https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation
Which does exactly what I said. Full zero knowledge attestation isn't practical as a single compromised key would give rise to a service that would serve everyone.
AFAIK no one uses blind signatures. It would enable the formation of commercial attestation farms.Apple uses Blind Signatures for attestation. It's how they avoid captchas at CloudFlare and Fastly in their Private Relay product
https://educatedguesswork.org/posts/private-access-tokens/
If I'm reading any of this correctly, this doesn't apply to hardware attestation.
It seems apple has a service, with an easily rotated key and an agreement with providers. If the key _Apple_ uses is compromised, they can rotate it.
BUT, apple knows _EXACTLY_ who I am. I attest to them using my hardware, they know _EXACTLY_ which hardware I'm using. They can ban me or my hardware. They then their centralized service gives me a blind token. But apple, may, still know exactly who owns which blind tokens.
However, I cannot generate blind tokens on my own. I _MUST_ talk to some centralized service that can I identify me. If that is not the case, then any single compromised device can generate infinite blind tokens rending all the tokens useless.
The idea behind blind signatures is that the server will give you a signed token which is blinded and you can un-blind it on your end and then use it. The consumer of the token will not be able to collude with the issuer of the token to figure out who it was given to. There is more info here: <https://blog.cloudflare.com/privacy-pass-the-math/>
I don't know if that's what Apple actually does. If it is, once it gets popular enough as an anti-bot measure there may be farms of Apple devices selling these tokens. It's a separate system from remote attestation anyhow.
I don't think that a 100% anonymous attestation protocol is what most people need and want.
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.
Most busunessed do not need origin attestation, they need history attestation.
I.e. from when they buy from a trusted source and init the device.
But what's it attesting? Their byline "Every system starts in a verified state and stays trusted over time" should be "Every system starts in a verified state of 8,000 yet-to-be-discovered vulns and stays in that vulnerable state over time". The figure is made up but see for example https://tuxcare.com/blog/the-linux-kernel-cve-flood-continue.... So what you're attesting is that all the bugs are still present, not that the system is actually secure.
Well, if a rootkit gets installed later, attention might be handy? Or am I missing something?
It comes rootkitted from the factory, and if you remove the rootkit, the device stops working.
I’m not sure I understand the threat model for this. Why would I need to worry about my enclave being identifiable? Or is this a business use case?
Or why buy used devices if this is a risk?
It's a privacy consideration. If you desire to juggle multiple private profiles on a single device extreme care needs to be taken to ensure that at most one profile (the one tied to your real identity) has access to either attestation or DRM. Or better yet, have both permanently disabled.
Hardware fingerprinting in general is a difficult thing to protect from - and in an active probing scenario where two apps try to determine if they are on the same device it's all but impossible. But having a tattletale chip in your CPU an API call away doesn't make the problem easier. Especially when it squawks manufacturer traceable serials.
Remote attestation requires collusion with an intermediary at least, DRM such as Widevine has no intermediaries. You expose your HWID (Widevine public key & cert) directly to the license server of which there are many and under the control of various entities (Google does need to authorize them with certificates). And this is done via API, so any app in collusion with any license server can start acquiring traceable smartphone serials.
Using Widevine for this purpose breaks Google's ToS but you would need to catch an app doing it (and also intercept the license server's certificate) and then prove it which may be all but impossible as an app doing it could just have a remote code execution "vulnerability" and request Widevine license requests in a targeted or infrequent fashion. Note that any RCE exploit in any app would also allow this with no privilege escalation.
Which is why I personally filed off the VIN from my car's engine.
I just put up 'do not track' flag in my browser:D
Why stop at the engine?
For most individuals it usually doesn’t matter. It might matter if you have an adversary, e.g. you are a journalist crossing borders, a researcher in a sanctioned country, or an organization trying to avoid cross‑tenant linkage
Remote attestation shifts trust from user-controlled software to manufacturer‑controlled hardware identity.
It's a gun with a serial number. The Fast and Furious scandal of the Obama years was traced and proven with this kind of thing
The scandal you cited was that guns controlled by the federal government don't have any obvious reasonable path to being owned by criminals; there isn't an obvious reason for the guns to have left the possession of the government in the first place.
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.
I assume the use case here is mostly for backend infrastructure rather than consumer devices. You want to verify that a machine has booted a specific signed image before you release secrets like database keys to it. If you can't attest to the boot state remotely, you don't really know if the node is safe to process sensitive data.
I'm confused. People talking about remote attestation which I thought was used for stuff like SGX. A system in an otherwise untrusted state loads a blob of software into an enclave and attests to that fact.
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.
At this point these are just English sentences. I am not worried about this threat model at all.
Please don't bring attestation to common Linux distributions. This technology, by essence, moves trust to a third party distinct of the user. I don't see how it can be useful in any way to end users like most of us here. Its use by corporations has already caused too much damage and exclusion in the mobile landscape, and I don't want folks like us becoming pariahs in our own world, just because we want machines we bought to be ours...
A silver lining, is it would likely be attempted via systemd. This may finally be enough to kick off a fork, and get rid of all the silly parts of it.
To anyone thinking not possibile, we already switched inits to systemd. And being persnickety saw mariadb replace mysql everywhere, libreoffice replace open office, and so on.
All the recent pushiness by a certain zealotish Italian debian maintainer, only helps this case. Trying to degrade Debian into a clone of Redhat is uncooth.
> A silver lining, is it would likely be attempted via systemd. This may finally be enough to kick off a fork, and get rid of all the silly parts of it.
This misunderstands why systemd succeeded. It included several design decisions aimed at easing distribution maintainers' burdens, thus making adoption attractive to the same people that would approve this adoption.
If a systemd fork differentiates on not having attestation and getting rid of an unspecified set of "all the silly parts", how would they entice distro maintainers to adopt it? Elaborating what is meant by "silly parts" would be needed to answer that question.
[flagged]
It was also heavily pushed by Red Hat by making everyone's lives harder if they didn't support it.
Attestation is a critical feature for many H/W companies (e.g. IoT, robotics), and they struggle with finding security engineers who expertise in this area (disclaimer: I used to work as a operating system engineer + security engineer). Many distros are not only designed for desktop users, but also for industrial uses. If distros ship standardized packages in this area, it would help those companies a lot.
This is the problem with Linux in general. It's way too much infiltrated by our adversaries from big tech industry.
Look at all the kernel patch submissions. 90% are not users but big tech drones. Look at the Linux foundation board. It's the who's who of big tech.
This is why I moved to the BSDs. Linux started as a grassroots project but turned commercial, the BSDs started commercial but are hardly still used as such and are mostly user driven now (yes there's a few exceptions like netflix, netgate, ix etc but nothing on the scale of huawei, Amazon etc)
Linux has been majority developed by large tech companies for the last 20+ years. If not for them, it would not be anywhere close to where it is today. You may not like this fact, but it's not really a new development nor something that can be described as infiltration. At the end of the day, maintaining software without being paid to do so is not generally sustainable.
Considering some of the changes to the ecosystem in the last 20 years it's not clear that this has made things better.
It is very clear that this has made things better
A lot more programs are available for linux, drivers and subsystems have gotten better, more features that benefit everyone (such as eBPF) and more
As a complete guess, I would say that 90% of Linux systems are run by "big tech drones". And also by small companies using technology.
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.
Only if you count Android phones as being run by Google ... which is exactly the problem we want to avoid with our PCs.
> This is why I moved to the BSDs. Linux started as a grassroots project but turned commercial
Thanks, this may be the key takeaway from this discussion for me
> Attestation is a critical feature for many H/W companies
Like John Deere. Read about how they use that sort of thing
IoT and robotics should (dare I say "must"?) not use general-purpose OSes at all.
This «Linux have a finger in every pie» attitude is very harmful for industry, IMHO.
Why shouldn't they use the kernel, systemd, and a few core utilities? Why reinvent the wheel? There's nothing requiring them to pull in a typical desktop userspace.
Because different tasks requires different trade-offs and Linux has only one set of trade-offs. You cannot do good universal tool. It is like Leatherman, good enough to fix-up your bike on the side of the road, not so for normal workshop.
You say: reinvent the wheel.
I say: use pickup truck for every task, from farming to racing to commuting moving goods across continent. Is it possible? Of course. Is it good idea? I don't think so.
All cars are the same if you squint enough, wheels, engine, some frame, some controls, which are not very different between even F1 car and 18-wheel truck.
How are you defining "general-purpose OS"? Are you saying IoT and robotics shouldn't use a Linux kernel at all? Or just not your general purpose distros? I would be interested to hear more of your logic here, since it seems like using the same FOSS operating system across various uses provides a lot of value to everyone.
I think, that I want at least hard-real-time OS in any computer which can move physical objects. Linux kernel cannot be it: hard RTOS cannot have virtual memory (mapping walks is unpredictable in case of TLB miss) and many other mechanisms which are desired in desktop/server OS are ill-suited for RTOS. Scheduler must be tuned differently, I/O must be done differently. It is not only «this process have RT priority, don't preempt it», it is design of whole kernel.
Better, this OS must be verified (as seL4). But I understand, that it is pipe dream. Heck, even RTOS is pipe dream.
About IoT: this word means nothing. Is connected TV IoT? I have no problems with Linux inside it. My lightbulb which can be turned on and off via ZigBee? Why do I need Linux here? My battery-powered weather station (because I cannot put 220v wiring in backyard)? Better no, I need as-low-power-as-possible solution.
To be honest, O think even using one kernel for different servers is technically wrong, because RDBMS, file server and computational node needs very different priories in kernel tuning too. I prefer network stack of FreeBSD, file server capabilities (native ZFS & Ko) of Solaris, transaction processing of Tandem/HPE NonStop OS and Wayland/GPU/Desktop support of Linux. But everything bar Linux is effectively dead. And Linux is only «good enough» in everything, mediocre.
I understand value of unification, but as engineer I'm sad.
I agree but it's difficult to argue against it. There is just so much you get for free by starting with a Linux distro as your base. Developing against alternatives is very expensive and developing something new is even more expensive. The best we can hope for is that someone with deep pockets invests in good alternatives that everyone can benefit from.
General purpose operating systems are fine and in some cases, preferable. However, they should be small, simple and designed with first class portability. Linux is none of those.
I'm not too big in this field but didn't many of those same IOT companies and the like struggle with the packages becoming dependent on Poeterings work since they often needed much smaller/minimal distros?
I don't think this is generally true. If you are running Linux in your stack, your device probably is investing in 1GiB+ RAM and 2GiB+ of flash storage. systemd et al are not a problem at that point. Running a UI will end up being considerably more costly.
I can assure you there are many Linux devices with specs significantly lower than that.
Sure, but devices that do that are not running a Linux distro off the shelf. They are creating something custom with the minimal amount of dependencies possible.
I work on embedded devices, fairly powerful ones to be fair, and I think systemd is really great, useful software. There's a ton of stuff I can do quite easily with systemd that would take a ton of effort to do reliably with sysvinit.
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.
Then they can go and buy some other OS like VxWorks.
It is already part of the most common Linux distribution, Android.
Please do, I disagree with this commenter.
You already trust third parties, but there is no reason why that third party can't be the very same entity publishing the distribution. The role corporations play in attestation for the devices you speak of can be displaced by an open source developer, it doesn't need to require a paid certificate, just a trusted one. Furthermore, attestation should be optional at the hardware level, allowing you to build distros that don't use it, however distros by default should use it, as they see fit of course.
I think what people are frustrated with is the heavy-handedness of the approach, the lack of opt-out and the corporate-centric feel of it all. My suggestion would be not to take the systemd approach. There is no reason why attestation related features can't be turned on or off at install time, much like disk encryption. I find it unfortunate that even something like secureboot isn't configurable at install time, with custom certs,distro certs, or certs generated at install time.
Being against a feature that benefits regular users is not good, it is more constructive to talk about what the FOSS way of implementing a feature might be. Just because Google and Apple did it a certain way, it doesn't mean that's the only way of doing it.
Whoever uses this seeks to ensure a certain kind of behavior on a machine they typically don't own (in the legal sense of it). So of course you can make it optional. But then software that depends on it, like your banking Electron app or your Steam game, will refuse to run... so as the user, you don't really have a choice.
I would love to use that technology to do reverse attestation, and require the server that handles my personal data to behave a certain way, like obeying the privacy policy terms of the EULA and not using my data to train LLMs if I so opted out. Something tells me that's not going to happen...
see latest "MS just divilged disk encryption keys to govt" news to see why this is a horrid idea
I’m skeptical about the push toward third-party hardware attestation for Linux kernels. Handing kernel trust to external companies feels like repeating mistakes we’ve already seen with iOS and Android, where security mechanisms slowly turned into control mechanisms.
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.
I can see usefulness if the flow was "the device is unlocked by default, there are no keys/certs on it, and it can be reset to that state (for re-use purpose)"
Then the user can put their own key there (if say corporate policies demand it), but there is no 3rd party that can decide what the device can do.
But having 3rd party (and US one too!) that is root of all trust is a massive problem.
oh hi ChatGPT
The giveaway is that LLMs love bulleted lists with a bolded attention-grabbing phrase to start each line. Copy-pasting directly to HN has stripped the bold formatting and bullets from the list, so the attention-grabbing phrase is fused into the next sentence, e.g. “Potential for abuse Attestation enables blacklisting”
Calling this a "giveaway" is kind of hilarious. LLMs use bulleted lists because humans have always used bulleted lists—in RFCs, design docs, and literally every tech write-up ever. Structure didn't suddenly become artificial in 2023. lol.
Yea but humans would have fixed it, this person didn't even bother. Straight copy and paste.
It could be an open source developer yes but in practice it's always the big tech companies. Look at how this evolved in mobile phones.
It's also because content companies and banks want other people in suits to trust.
[dead]
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?
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.
Thanks for the clarification and to be clear, I don't doubt your personal intent or FOSS background. The concern isn't bad actors at the start, it's how projects evolve once they matter.
History is pretty consistent here:
WhatsApp: privacy-first, founders with principles, both left once monetization and policy pressure kicked in.
Google: 'Don’t be evil' didn’t disappear by accident — it became incompatible with scale, revenue, and government relationships.
Facebook/Meta: years of apologies and "we'll do better," yet incentives never changed.
Mobile OS attestation (iOS / Android): sold as security, later became enforcement and gatekeeping.
Ruby on Rails ecosystem: strong opinions, benevolent control, then repeated governance, security, and dependency chaos once it became critical infrastructure. Good intentions didn't prevent fragility, lock-in, or downstream breakage.
Common failure modes:
Enterprise customers demand guarantees - policy creeps in.
Governments demand compliance - exceptions appear.
Liability enters the picture - defaults shift to "safe for the company."
Revenue depends on trust decisions - neutrality erodes.
Core maintainers lose leverage - architecture hardens around control.
Even if keys are user-controlled today, the key question is architectural: Can this system resist those pressures long-term, or does it merely promise to?
Most systems that can become centralized eventually do, not because engineers change, but because incentives do. That’s why skepticism here isn't personal — it's based on pattern recognition.
I genuinely hope this breaks the cycle. History just suggests it's much harder than it looks.
Did AI write this comment?
nope. why?
Can you (or someone) please tell what’s the point, for a regular GNU/Linux user, of having this thing you folks are working on?
I can understand corporate use case - the person with access to the machine is not its owner, and corporation may want to ensure their property works the way they expect it to be. Not something I care about, personally.
But when it’s a person using their own property, I don’t quite get the practical value of attestation. It’s not a security mechanism anymore (protecting a person from themselves is an odd goal), and it has significant abuse potential. That happened to mobile, and the outcome was that users were “protected” from themselves, that is - in less politically correct words - denied effective control over their personal property, as larger entities exercised their power and gated access to what became de-facto commonplace commodities by forcing to surrender any rights. Paired with awareness gap the effects were disastrous, and not just for personal compute.
So, what’s the point and what’s the value?
The value is being able to easily and robustly verify that my device hasn't been compromised. Binding disk encryption keys to the TPM such that I don't need to enter a password but an adversary still can't get at the contents without a zero day.
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".
> For example I have no idea what they mean by the bullet "runtime integrity".
This is for example dm-verity (e.g. `/usr/` is an erofs partiton with matching dm-verity). Lennart always talks about either having files be RW (backed by encryption) or RX (backed by kernel signature verification).
I don’t think attestation can provide such guarantees. To best of my understanding, it won’t protect from any RCE, and it won’t protect from malicious updates to configuration files. It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware). IDSes are sufficient for this purpose, without negative side effects.
And that’s why I said “not a security mechanism”. Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.
I think all of that comes down to being a matter of what precisely you're attesting? So I'm not actually clear what we're talking about here.
Given secure boot and a TPM you can remotely attest, using your own keys, that the system booted up to a known good state. What exactly that means though depends entirely on what you configured the image to contain.
> it won’t protect from malicious updates to configuration files
It will if you include the verified correct state of the relevant config file in a merkel tree.
> It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware).
Shouldn't it permit running arbitrary binaries that you have signed? That places the root of trust with the build environment.
Now if you attempt to compile binaries and then sign them on the production system yeah that would open you up to attack (if we assume a process has been compromised at runtime). But wasn't that already the case? Ideally the production system should never be used to sign anything. (Some combination of SGX, TPM, and SEV might be an exception to that but I don't know enough to say.)
> Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.
If you remotely boot a box sitting in a rack on the other side of the world how can you be sure it hasn't been compromised? However you go about confirming it, isn't that what attestation is?
Well, maybe we're talking about different things, because I've asked from a regular GNU/Linux user perspective. That is, I have my computers and I'm concerned I would lose my freedoms to use them as I wish, because this attestation would be adopted and become de-facto mandatory if I ever want to do something online. Just like what happened to mobile, and what's currently slowly happening to other desktop OSes.
Production servers are a whole different story - it's usually not my hardware to begin with. But given how things are mostly immutable those days (shipped as images rather than installed the old-fashioned sysadmin way), I'm not really sure what to think of it...
You originally asked what the value proposition for a regular (non-corporate) user was. Then you raised some objections to my answer (or at least so I thought).
Granted these technologies can also be abused. But that involves running third party binaries that require SGX or other DRM measures before they will unlock or decrypt content or etc. Or querying a security element to learn who signed the image that was originally booted. Devices that support those things are already widespread. I don't think that's what this project is supposed to be. (Although I could always be wrong. There's almost no detail provided.)
https://attestation.app/about For mobiles, it helps make tampering obvious.
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.
Laptops can already have TPM based on FLOSS (with coreboot with Heads). It works well with Qubes btw, and is recommended by the developers: https://forum.qubes-os.org/t/qubes-certified-novacustom-v54-...
The "founding engineers" behind Facebook and Twitter probably didn't set out to destroy civil discourse and democracy, yet here we are.
Anyway, "full control over your keys" isn't the issue, it's the way that normalization of this kind of attestation will enable corporations and governments to infringe on traditional freedoms and privacy. People in an autocratic state "have full control over" their identity papers, too.
> 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.
I am aware of that, my (personal) view is that DRM is a social issue caused by modes of behaviour and the existence or non-existence of technical measures cannot fix or avoid that problem.
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-...
This whole discussion is a perfect example of what Upton Sinclair said, "It is difficult to get a man to understand something, when his salary depends on his not understanding it."
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.
You could tell this sort of insinuation to anyone. Including you.
Argument should be technical.
Insinuation? As a sw dev they don't have any agency over whether or by whom they get acquired. Their decision will be whether to leave if it's changing to the worse, and that's very much understandable (and arguably the ethical thing to do).
That's a perfectly valid objection to this proposal. You only have to look at what happened to Hashicorp to see the risk.
Technical arguments pave the road to hell.
Well he is called faust…
> You could tell this sort of insinuation to anyone. Including you.
Yes. You correctly stated the important point.
> Argument should be technical.
Yes. Aleksa made no technical argument.
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?
I'm really not trying to be slick, but I think it's quite difficult to convince people about anything concrete (such as precisely how this model is fundamentally different to models such as the Secure Boot PKI scheme and thus will not provide a mechanism to allow a non-owner of a device to restrict what runs on your machine) without providing a concrete implementation and design documents to back up what I'm saying. People are rightfully skeptical about this stuff, so any kind of explanation needs to be very thorough.
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
>I think that technological measures cannot fix a social problem
The absence of technological measures used to implement societal problems totally does help though. Just look at social media.
I fear the outlaw evil maid or other hypothetical attackers (good old scare-based sales tactics) much less than already powerful entities (enterprises, states) lawfully encroaching on my devices using your technology. So, I don't care about "misunderstandings" of the TPM or whatever other wall of text you are spewing to divert attention.
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.
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.
> 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.
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
What was it that the Google founders said about not adding advertisements to Google search?
> The models we have in mind for attestation are very much based on users having full control of their keys.
If user control of keys becomes the linchpin for retaining full control over one's own computer, doesn't it become easy for a lobby or government to exert control by banning user-controlled keys? Today, such interest groups would need to ban Linux altogether to achieve such a result.
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.
Can I build my own kernel and still use software that wants attestation?
Do you have a way to tell the software to trust your kernel? If so, yes. Things like the web show how we can achieve distributed trust.
"Trust" has become such an orwellian word in tech.
That's the thing. I can only provide a piece of software with the guarantee it can run on my OS. It can trust my kernel to let it run, but shouldn't expect anything more. The editor is free to run code it wants to guarantee the integrity of on its own infrastructure; but whatever reaches my machine _may_ at best run as the editor intends.
> The models we have in mind for attestation are very much based on users having full control of their keys.
FOR NOW. Policies and laws always change. Corporations and governments somehow always find ways to work against their people, in ways which are not immediately obvious to the masses. Once they have a taste of this there's no going back.
Please have a hard and honest think on whether you should actually build this thing. Because once you do, the genie is out and there's no going back.
This WILL be used to infringe on individual freedoms.
The only question is WHEN? And your answer to that appears to be 'Not for the time being'.
> 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.
The road to hell is paved with good intentions.
That's not the intention, but how do you stop it from being the effect?
Glad to hear it! I am not surprised given the names and the fact you're at FOSDEM.
What engineering discipline?
PE or EIT?
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?
TLDR We already know how this will be misused to take away people's freedom not to run their own software stack but to dissent against fascism. It's immoral to build even with the best intentions.
You're providing mechanism, not policy. It's amazing how many people think they can forestall policies they dislike by trying to reject mechanisms that enable them. It's never, ever worked. I'm glad there are going to be more mechanisms in the world.
half of the founders of this thing come from Microsoft. I suppose this makes the answer to your question obvious.
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.
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.
Afaik bankid will actually run as long as you can install play store (IE the device don't need Google certificate), which isn't great but a little bit better than what it could have been.
That can't be right. My onyx boox note air 2 eInk tablet lets me install the google play store by registering myself as an AOSP developer and enrolling my device's serial number or GSF identifier with Google using some Google Form that some android team somewhere's automated by now. The device has no hardware security features from what I can tell. There's no way this platform would pass muster with any bank.
At least BankId (digital ID thing in Sweden) and some of the Swedish banking apps don't care about if you are rooted on stock Android. I haven't tried custom ROMs in many years, but perhaps it is time for GrapheneOS these days.
Now, if you want to use your phone as a debit/credit card substitute that is different (Google Pay cares, and I don't use it thus).
Anyway, why should banking apps care? It is not like they care when I use the bank from Firefox on my Linux laptop.
> There's no way this platform would pass muster with any bank
"Any bank"? Although the bank I use locks NFC payments behind such checks (which is not a big loss since a physical debit card offers the same functionality), anything else still works otherwise. Most of the things are available through the website (which fits well on mobile too), and mobile BLIK payments can be done from the Android app which works inside Waydroid with microG.
There's no reason other banks can't work the same way and it's outraging when they don't. Look around for a better bank.
I have the successor device, the Boox Note Air 2, and don't remember how I installed Google Play on it, it was so easy as to be not even notable. Though almost everything I use is available on F-Droid other than my fancy calendar and contacts applications.
The bank doesn't have to actually be secure, only tick certain boxes.
I just received by mail a card to replace my soon expiring one… (not a debt card, the one to do internet banking and so on).
However the problem is that A LOT of things only work with the mobile app.
as you say, a lot of this stuff is already happening. Won’t it be good to have a FOSS attestation stack that breaks the iOS/android duopoly?
Banks don't use these things because they provide any real security. They use them because the platform company calls it a "security feature" and banks add "security features" to their checklists.
The way you defeat things like that is through political maneuvering and guile rather than submission to their artificial narrative. Publish your own papers and documentation that recommends apps not support any device with that feature or require it to be off because it allows malware to use the feature to evade malware scans, etc. Or point out that it prevents devices with known vulnerabilities from being updated to third party firmware with the patch because the OEM stopped issuing patches but the more secure third party firmware can't sign an attestation, i.e. the device that can do the attestation is vulnerable and the device that can't is patched.
The way you break the duopoly is by getting open platforms that refuse to support it to have enough market share that they can't ignore it. And you have to solve that problem before they would bother supporting your system even if you did implement the treachery. Meanwhile implementing it makes your network effect smaller because then it only applies to the devices and configurations authorized to support it instead of every device that would permissionlessly and independently support ordinary open protocols with published specifications and no gatekeepers.
Well summarised.
Another point is (often )the apps that banks makes are 3rd party developed by outsourcing (even if within the same developed country). If someone uses some MiTM or logcat to see some traffic and publishes it then banks get bad publicity. So to prevent this the banks, devs tell anything that is not normal (i.e) non-stock ROM is bad.
FOSS is also something many app-based software devs don't like on their products. While people in cloud, infra like it the app devs like these tools while developing or building a company but not when making end resulting apps.
Remote attestation absolutely provides increased security. Mobile banking fraud rates are substantially lower than desktop/browser banking fraud. Attestation is major reason why.
I think ever compute professional needs to spend at least a year trying to secure a random companies windows network to appreciate how impossible this actually is without hardware based roots of trust like TPMs and HSMs
>Attestation is major reason why.
It's not. Mobile applications just don't have unrestricted access to everything in your user directory, attestation have nothing to do with it.
It's not even that. The main reason is probably that attackers are going to be writing code to automate their attacks, and desktops are easier to develop on than phones, so that's what they use with no reason to do otherwise.
Even if you stopped supporting desktops, then they would just reverse engineer the mobile app instead of the web app and extract the attestation keys from any unpatched model of phone and still run their code on a server, and then it would show up as "mobile fraud" because they're pretending to be a phone instead of a desktop, when in reality it was always a server rather than a phone or a desktop.
And even if attestation actually worked (which it doesn't), that still wouldn't prevent fraud, because it only tries to prove that the person requesting the transfer is using a commercial device. If the user's device is compromised then it doesn't matter if it can pass attestation because the attacker is only running the fake, credential stealing "bank app" on the user's device, not the real bank app. Then they can run the official bank app on an official device and use the stolen credentials to transfer the money. The attestation buys you nothing.
All this theatre is turning out to be nothing more than giving up the agency we have today (nice things), for a risk averse kneejerk runaround with glaring ulterior motives...just like the scan your face+id push for services.
Would YOU be willing to use a bank that refused to use TLS? I didn't think so. How is you refusing to accept remote attestation and the bank refusing to connect to you any different?
Because Banking has existed and operated fine for countless decades without it(attestation).
Also, as there is ample discussion elsewhere, having attestation does NOT eliminate the ability for your account to become compromised.
As restated.
"If the user's device isn't compromised then everything is fine regardless of whether or not it can pass attestation. If the user's device is compromised, the device doesn't need to pass attestation to run a fake bank app and steal the user's credentials. Once the attacker has the user's credentials they can use them to transfer money regardless of whether or not they have to use a different device that can pass attestation.
It doesn't really provide any security."
IT DOES however completely rewrite the paradigm of general purpose computing in very asymmetrical ways.
Are you saying that attestation doesn't really provide any real security? Not even from the bank's point of view?
If the user's device isn't compromised then everything is fine regardless of whether or not it can pass attestation. If the user's device is compromised, the device doesn't need to pass attestation to run a fake bank app and steal the user's credentials. Once the attacker has the user's credentials they can use them to transfer money regardless of whether or not they have to use a different device that can pass attestation.
It doesn't really provide any security.
On top of that, there are tons of devices that can pass attestation that have known vulnerabilities, so the attacker could just use one of those (or extract the keys from it) if they had any reason to. But in the mobile banking threat model they don't actually need to.
So do we just give up because it's too hard?
It's not a matter of being hard. It's like trying to prevent theft by forcing everyone to wear a specific brand of shoes. The fact that the shoe company insists that it's useful is not evidence that it is.
It's not that you can't solve the problem, it's that you can't solve the problem using that mechanism. Attestation is useless for this.
The thing that would actually work for this is to have an open standard supported by PCs and phones to read the chip in payment/ATM cards, because then you could do "card-present" transactions remotely. You touch your card to the phone/PC and enter your PIN to authorize a new merchant. That actually solves the problem because then instead of the bank trusting every commercially available phone on the market, they only trust the specific card that they mailed to the cardholder, and you can only authorize a new merchant with physical possession of the card because it contains a private key. But that doesn't require attestation because then you don't need the keys to be in the phone since they're in the card, and it doesn't require a third party to sign anything because the bank puts the private key into the card before sending it to the cardholder without any need for Google or Apple to certify anything.
My head hurts now...
Well, it depends. I can now do banking from my desktop computer because there is no way our banks can attest that we're running our browsers in their approved hardware+software stack. Of course they can already disable banking from the browser but if they choose to keep it open but require attestation in your browser when it becomes possible, I don't think it's a good thing.
It would but how and who to run it? Ideally some one like Linux Foundation sits on the White house meetings or EU meetings. But they don't. Govts don't understand. I was once participating in a Youth meeting with MEPs - most of them have only iPhones. Most (not all) lawmakers live on a different planet.
Also IIRC, linux foundation etc are not interested in doing such standardisations.
No
This is already the world we live in when it comes to the most popular personal computing devices running Linux out there.
This is already the world you live in just running some recent Ubuntu. Try writing, building and loading a kernel module!
Of course its all nonsense make believe, the "trust root" is literally a Microsoft signed stub. For this dummy implementation you can't modify your own kernel anymore.
And you cannot remove it on every motherboard because some of the firmware blobs are signed. You cannot remove their keys and leave only your own.
Torrenting is becoming more popular again. The alternative to being allowed to pay to watch on an "insecure" device isn't switching to an attested device, it's to stop paying for the content at all. Games industry, same thing (or just play the good older games, the new ones suck anyway).
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.
Is the joke here that all of those things have already been happening for a while now?
that's a silver lining
the anti-user attestation will at least be full of security holes, and likely won't work at all
Dunno about the others but Pottering has proven himself to deliver software against the grain.
You think?
It took us nearly a decade and a half to unfuck the pulseaudio situation and finally arrive at a simple solution (pipewire).
SystemD has a lot more people refining it down but a clean (under the hood) implementation probably won't be witnessed in my lifetime.
anyone who thinks that pipewire - pipewire! - is "a simple solution" understands nothing about pipewire.
don't get me wrong, i use pipewire all day every day, and wrote one of the APIs (JACK) that it implements (pretty well, too!).
but pipewire is an order of magnitude more complex than pulseaudio.
As an end user hand assembling desktop services on non-Systemd distros (Artix, Devuan, Gentoo, Guix) over the years, and thus had no concern about APIs, Pipewire just works and PulseAudio gave endless trouble.
My 0.02 bits.
As another user on Gentoo, pipewire is a never ending pain in the ass full of "magic" behavior and weird bugs. I mostly skipped pulse though so it may be simple in comparison to that.
yeah, the fix for pulseaudio was to throw it away entirely
for systemd, I don't think I have a single linux system that boots/reboots reliably 100% of the time these days
There were dozens of other init systems that, like systemd, wasn't a shell script.
What set systemd apart is the collection of tightly integrated utilities such as a dns resolver, sntp client, core dump handler, rpc-like api linking to complex libraries in the hot path and so on and so forth that has been a constant stream of security exploits for over a decade now.
This is a case where the critics were proven to be right. Complexity increases the cognitive burden.
As predicted. I thought pulseaudio should have been enough of a lesson. Besides that, any person that works on open source but that joins Microsoft is not in the camp that should have a say in the overall direction of Linux.
"People don't learn lessons" is a lesson that people don't learn.
What set systemd apart was RedHat, and now Pottering repeats the old trick with Microsoft behind his back.
I think he will succeed and we will be worse off, collectively.
that on itself is not a problem. The problem is that those work worse.
For example, the part of systemd that fills DNS will put them in random order (like actual random, not "code happened to dump it in map order)
The previous, while very much NOT perfect, system, put the DNSes in order of one in latest interface, which had useful side-feature that if your VPN had different set of DNSes, it got added in front
The systemd one just randomizes it ( https://github.com/systemd/systemd/issues/27543 ) which means that using standard openvpn wrapper script for it will need to be reran sometimes few times to "roll" the right address, I pretty much have to run
half of the time I connect to company's VPNThe OTHER problem is pervasive NIH in codebase.
Like, they decided to use binary log format. Okay, I can see advantages, it can be indexed or sharded for faster access to app's files...
oh wait it isn't, if you want to get last few lines of a service the worst case is "mmap every single journal file for hundreds of MBs of reads"
It can be optimized so some long but constant fields like bootid are not repeated...
oh wait it doesn't do that either, is massively verbose. I guess I can understand it, at least that would make it less crash-proof...
oh wait no, after crash it just spams logs that previous log file is corrupted and it won't be used.
So we have a log format that only systemd tools can read, takes few times as much space per line as text or even JSON version would, and it still craps out on unclean shutdown
They could've just integrated SQLite. Hell I literally made a lil prototype that took journalctl logs and wrote it to indexed SQLite file and it was not only faster but smaller (as there is no need to write bootid with each line, and log lines can be sharded or indexed so lookup is faster). But nah, Mr. Poettering always wanted to make a binary log format so he did.
The trick is the same: use a popular linux distribution and don't fight the kinks.
The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way.
SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work that makes systemd function smooth.
I was today years old when I realised this is true for both bits of poetter-ware. Weird.
I only use debian
pulseaudio I had to fight every single day, with my "exotic" setup of one set of speakers and a headset
with pipewire, I've never had to even touch it
systemd: yesterday I had a network service on one machine not start up because the IP it was trying to bind to wasn't available yet
the dependencies for the .service file didn't/can't express the networking semantics correctly
this isn't some hacked up .service file I made, it's that from an extremely popular package from a very popular distro
(yeah I know, use a socket activated service......... more tight coupling to the garbage software)
the day before that I had a service fail to start because the wall clock was shifted by systemd-timesyncd during startup, and then the startup timeout fired because the clock advanced more than the timeout
then the week before that I had a load of stuff start before the time was synced, because chrony has some weird interactions with time-sync.target
it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc
for what? to save maybe a second of boot time
if the distro maintainers don't understand the systemd dependency model after a decade then it's unfit for purpose
> it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc
This gave me a good chuckle. Systemd literally was created to solve the awful race conditions and non-determinism in other init systems. And it has done a tremendous job at it. Hence the litany of options to ensure correct order and execution: https://www.freedesktop.org/software/systemd/man/latest/syst...
And outside of esoteric setups I haven't ever encountered the problems you mentioned with service files.
systemd was created to solve the problems of a directory full of shell scripts. A single shell script has completely different problems. And traditional init uses inittab, which is not /etc/init.d, and works more like runit.
runit's approach is to just keep trying to start the shell script every 2 seconds until it works. One of those worse–is–better ideas, it's really dumb, and effective. You can check for arbitrary conditions and error–exit, and it will keep trying. If you need the time synced you can just make your script fail if the time is not synced.
traditional inittab is older than that and there's not any reason to use it when you could be using runit, really.
yeah, many options that are complicated beyond the understanding of the distro maintainers, and yet still don't allow expression of common semantics required to support network services reliably
like "at least one real IP address is available" or "time has been synced"
and it's not esoteric, even ListenAddress with sshd doesn't even work reliably
the ONLY piece of systemd I've not had problems with is systemd-boot, and then it turned out they didn't write that
> like "at least one real IP address is available" or "time has been synced"
"network-online.target is a target that actively waits until the network is “up”, where the definition of “up” is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network has been set up."
For time sync checks, I assume one of the targets available will effectively mean a time sync has happened. Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one.
it's the "usually" that's the problem
this service (untouched by me) had:
After=local-fs.target network-online.target remote-fs.target time-sync.target
but it was still started without an IP address, and then failed to bind
just like this sort of problem: https://github.com/systemd/systemd/issues/4880#issuecomment-...
the entire thing is unreliable and doesn't act like you'd expect
> Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one.
at that point I might as well go back to init=/etc/rc
Are you running this particular unit file as a user unit or a system unit? Some targets like network-online.target don't work from user unit files.
You could also try targeting NetworkManager or networkd's "wait-online" services. Or if that doesn't work, something is telling systemd that you have an IP when you don't. NetworkManager has "ipv4.may-fail" and "ipv6.may-fail" that might be errenously true.
> at that point I might as well go back to init=/etc/rc
The difference is that systemd is much better at ensuring correctness. If you write the invoked shell command properly, it'll communicate failure or success correct and systemd will then communicate that state to the unit. It's still a lot more robust than before.
it's a system service file
the problem is systemd
> The difference is that systemd is much better at ensuring correctness.
yeah, whatever mate
Seems like you have an axe to grind with systemd because it replaced your familiar (but extremely cruddy) init system and now you refuse to debug the problem because you prefer being able to blame systemd.
There is so much granularity and flexibility in what you can do it seems rather unlikely you cannot make it happen correctly. And if it is truly a bug... open an issue? They're rather responsive to it. And it isn't like the legacy init systems were bug free from inception (well, lord knows they were still chock full of bugs even when they were replaced).
Edit: sitting here with a grin .. HN downvoting the advice of checking logs, debugging and opening an issue. I wish the companies y'all work at good luck.. they'll need it.
> Seems like you have an axe to grind with systemd because it replaced your familiar (but extremely cruddy) init system and now you refuse to debug the problem because you prefer being able to blame systemd.
I'm a pragmatist: I just want it to work
my solution to MULTIPLE different services failing to IP bind is to turn on the non-local ip binding sysctl, bypassing systemd's brokenness entirely
> There is so much granularity and flexibility in what you can do it seems rather unlikely you cannot make it happen correctly.
I've written an init before (in C), I know how the netlink interface to set an IP address and add routing table entries works
I understand the difference between monotonic and wall clocks
I understand the difference between Wants and Require
I know what's going on at every, single, level
and I can't stand how unreliable systemd makes nearly every single one of my, bluntly, completely vanilla systems
> And if it is truly a bug... open an issue?
did you read the link I pasted earlier?
I'm not wasting my time with that level of idiocy (from LP himself)
> Some targets like network-online.target don't work from user unit files.
So basically it just doesn't work sometimes for no particular reason.
> The difference is that systemd is much better at ensuring correctness
Uh, well, you just said that it isn't, because some targets like network-online.target don't work from user unit files.
> https://github.com/systemd/systemd/issues/4880
I'm not a systemd hater or anything, but I continue to read stuff from Poettering which to me is deeply disturbing given the programs he works on.
Saying it's not a bug that service is launched despite a stated required prerequisite dependency failed... WTF?
Sure, I agree with him that most computers should probably boot despite NTP being unable to sync. But proposing that the solution to that is breaking Requires is just wild to me.
I'm not sure I understand why you think the solution proposed there is so bad.
The question in that issue is around the semantics of time-sync.target. Targets are synchronization points for the system and don't (afaik) generally make promises about the units that are ordered before them (in this case chrony-wait.service.
Does that answer your specific objection of "proposing that the solution to that is breaking Requires is just wild to me"? Basically, what is proposed in that issue is not breaking Requires=. The proposition is that the user add their own, specific Requires= as a drop-in configuration since that's not a generally-applicable default.
No, that does not make sense, because it goes against the systemd documentation.
Targets[1]: Target units do not offer any additional functionality on top of the generic functionality provided by units. They merely group units, allowing a single target name to be used in Wants= and Requires= settings to establish a dependency on a set of units defined by the target, and in Before= and After= settings to establish ordering.
boot-complete.target[2]: Order units that shall only run when the boot process is considered successful after the target unit and pull in the target from it, also with Requires=.
Note use of "only run" with a reference to Requires=.
time-sync.target[3]: This target provides stricter clock accuracy guarantees than time-set.target (see above), but likely requires network communication and thus introduces unpredictable delays. Services that require clock accuracy and where network communication delays are acceptable should use this target.
Especially note the last sentence there.
The documentation clearly indicates that targets can fail, and that services that needs the target to be successful, should use Requires= to specify that.
If the above is not true, the Requires= and Targets documentation should be rewritten to explicitly say that targets might fulfill Requires= regardless of state. Also, the documentation for time-sync.target should explicitly remove the last sentence and instead state there is no functional difference between Requires=time-sync.target and Wants=time-sync.target, it is best-effort only.
[1]: https://www.freedesktop.org/software/systemd/man/latest/syst...
[2]: https://www.freedesktop.org/software/systemd/man/latest/syst...
[3]: https://www.freedesktop.org/software/systemd/man/latest/syst...
That seems like a fair point about the documentation! As far as I can see, you're right.
So that's why I find his statements disturbing.
If he really don't want targets to deliver failed/success guarantees, then they've massively miscommunicated in their documentation. That in my book is a huge deal.
In either case the issue should in no circumstance be casually dismissed as not-a-bug without further action.
I don't personally find it as disturbing as you do, I think. Which isn't to say that I don't think it should be fixed, etc. etc.
I'm sure the project would accept a documentation patch to amend this discrepancy. At the end of the day (despite what some people on the internet might like to allege), systemd is a free software project that, despite having (more or less) a BIFL, is ultimately a relatively bazaar-like project.
Though since these targets and unit properties are very core to systemd-the-service manager, I do think that this is a bigger documentation oversight than most.
The disturbing part isn't the bug in time-sync.target or documentation, the disturbing part is how casually he brushes the issue away.
To me this is a huge red flag for a senior contributer to a core systems component, signalling some fundamental lack of understanding or imagination.
I very much disagree with not fixing time-sync.target, but if he had instead written a well-reasoned explanation for why time-sync.target should not propagate failed states and flagging it as a documentation bug, then that's something I'd respect and would be fine with. Or, even better IMHO, he'd fix time-sync.target and state that users who wants to boot regardless should use Wants instead.
Is it possible for network-online to mean that, or does network-on actually mean that?
It is possible for a specification to be so abstract that it's useless.
That's entirely defined by whatever units order themselves before network-online.target (normally a network management daemon like NetworkManager or systemd-networkd). systemd itself doesn't define the details; that's left up to how that distro and sysadmin have configured the network manager/system.
Sysadmins really hate the word "usually", and that is at the root of just about every systemd headache I've had
Same. I run a server with a ton of services running on it which all have what I think are pretty complex dependency chains. And I also have used Linux with systemd on my laptop. Systemd has never, once, caused me issues.
I can totally relate to this, it's gotten to the point that I'm just as scared of rebooting my Linux boxes as I was of rebooting my windows machine a couple of decades ago. And quite probably more scared.
everyone attacking Microslop for a bug where Windows won't shut down properly
well, systemd's got them beat there!
The good thing about systemd or any other Linux software is that you don't have to use it, until this company gets off the ground.
I think at some point we will see a steep increase in value of old hardware that can still run unsigned binaries.
It won't be able to interact with any online services like Google or Hacker News.
Ah, we will get more done. Or maybe just see you on the mailing list and IRC?!
You will always be able to interact with rsync.net …
… and the warrant canary we publish every Monday morning.
Google I can live without ;)
What distro?
The box that I'm worried about in particular is running RedHat.
Ubuntu boxes: usually ok as long as you stay away from anything python related in the core system.
"for what? to save a second of boot time"
Doubtful the motivation was /etc/rc being too slow
daemontools, runit, s6 solve that problem
The only parties that really cared about boot time were the big hosting providers and container schleppers. For desktop linux it never mattered as much.
For me, randomly missing NFS mounts after boot were the last straw. I could not solve this problem. I am back on sysv init.
This. If you set an NFS share, it better be there forever and ever.
PipeWire is like 10 years newer than PulseAudio. It probably had a chance to learn some lessons!
IIRC before PulseAudio we had to mess around with ALSA directly (memory hazy, it was a while ago). It could be a bit of a pain.
PipeWire was also made by a guy with a lot of multimedia experience (GStreamer).
ALSA was kind of OK after mixing was enabled by default and if you didn't need to switch outputs of a running application between anything but internal speakers and headphones (which worked basically in hardware). With any additional devices that you could add and remove, ALSA became a more serious limitation, depending. You could usually choose your audio devices (including microphones) at least at the beginning of a video conference / playing a movie etc, but it was janky (unreliable, list of 20 devices for one multi-channel sound card) and needed explicit support from all applications. Not sure if it ever worked with Bluetooth.
> Not sure if it ever worked with Bluetooth.
It does, with the help of BlueALSA[0].
[0] https://github.com/arkq/bluez-alsa
I remember ALSA. Sure, it was finnicky to use `alsamixer` to unmute the master channels now and then, but I personally never had any trouble with it.
I still need to use alsamixer to unmute my headphones after accidentally unplugging them and plugging them in again fails to do so. That's with PipeWire - never had that problem with just ALSA.
Eh, I had to do that with pulseaudio too, but constantly, across all distros and headphones. Pipewire is shonky, I have to restart now and then on my steam deck (I'm using it as a desktop), but it's still much better than pulseaudio. Even ALSA was better than pulseaudio lol
Alsa with dmix is my current setup on ArchLinux.
I installed Gentoo in 2014 and getting PulseAudio working was much easier than ALSA. It was also much better.
I get ALSA followed the Unix philosophy of doing one thing but I want my audio mixer to play multiple sounds at once.
Gentoo in 2014 had dmix enabled by default without the need for any user configuration. I know because I was using it.
I got stuck for two weeks installing the kernel because I forgot to mount /boot. Perhaps I disabled it by accident when goofing around in alsamixer? Or my card did or didn't have hardware mixing?
I didn't actually know anything about Linux at the time and started with Gentoo because I saw a meme saying "install Gentoo" and people told me not to start with that distro. So it's possible I messed up the default config by accident.
Either way PulseAudio worked after I emerged it.
Debian is a darling for which I will always love, but it's inability to deal with systemd is one of the prime reasons I left.
I am not seeing these kind of systemd issues with Fedora / RHEL.
It just works
That's because systemd originated at RedHat. If it had been designed distribution agnostic it would have worked a lot better on other distros besides RH.
What are the non-distribution agnostic parts of systemd? Considering it runs as PID1 (usually) it kinda is the base of distros and not really built on top of any distro other than "the linux kernel".
"The trick is the same: use a popular linux distribution and don't fight the kinks."
I believe that you are genuinely being sincere here, thinking this is good advice.
But this is an absolutely terrible philosophy. This statement is ignorant as well as inconsiderate. (again, I do believbe you don't intend to be inconsiderate consciously, that is just the result.)
It's ignorant of history and inconsiderate of everyone else but yourself.
Go back a few years and this same logic says "The trick is, just use Windows and do whatever it wants and don't fight."
So why in the world are you even using Linux at all in the first place with that attitude? For dishonest reasons (when unpacked to show the double standard).
Since you are using Linux instead of Windows, then you actually are fine with fighting the tide. You want the particular bits of control you want, and as long as you are lucky enough to get whatever you happen to care about without fighting too much, then you have no sympathy for anyone else who cares aboiut anything else.
You don't see yourself as fighting any tides because you are benefitting from being able to use a mainstream distro without customizing it. But the only reason you get to enjoy any such thing at all in the first place is because a lot of other people before you fought the tide to bring some mainstream distros into existence, and actually use them for ordinary activities enough despite all the difficulties, to force at least some companies and government agencies to acknowledge them. So now you can say things like "just use a mainstream distro as it comes and don't try to do what you actually want".
> Go back a few years and this same logic says "The trick is, just use Windows and do whatever it wants and don't fight."
This is basically exactly what I saw people saying in Windows subreddits. There's one post that particularly sticks out in my memory[0] that basically had everybody telling the OP to just not make any of the changes that they wanted to make. The advice seemed to revolve around adapting to the OS rather than adapting the OS to you, and it made me sad at the time.
[0] https://www.reddit.com/r/Windows10/comments/hehrqe/what_are_...
I read it as sarcastic and bitter, personally! I believe you are both agreeing :)
hah it fits regardless
> The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way.
Incorrect. I used mainstream distro, still had issues, that just solved itself moving to pipewire. Issues like it literally crashing or emitting spur of max volume noise once every few months for no discernable reason.
Pulseaudio also completely denies existence of people trying to do music on Linux, there is no real way to make latency on it be good.
> SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work that makes systemd function smooth.
Over the years of using the "opinion" of SystemD seems to be "if it is not problem on Lennart's laptop, it's not a real problem and it can be closed or ignored completely".
For example systemd have no real method to tell it "turn off all apps after 5 minutes regardless of what silly package maintainers think". Now what happens if you have a server on UPS that have say 5 minutes of battery and one of the apps have some problem and doesn't want to close?
In SysV, it gets killed, and system gets remounted read only. You have app crash recovery but at least your filesystem is clean In systemd ? No option to do that. You can set default timeout but it can be override in each service so you'd have to audit every single package and tune it to achieve that. That was one bug that was closed.
Same problem also surfaced if you have say app with a bug that prevented it from closing from sigterm and you wanted to reboot a machine. Completely stuck
But wait, there is another method, systemd have an override, you can press (IIRC) ctrl+alt+delete 7 times within 2 seconds to force it to restart ( which already confuses some people that expect it to just restart machine clean(ish) regardless https://github.com/systemd/systemd/issues/11285 ).
...which is also impossible if your only method of access is software KVM where you need to navigate to menu to send ctrl+alt+del. So I made ticket with proposal to just make it configurable timeout for the CAD ( https://github.com/systemd/systemd/issues/29616 ), the ticket wasn't even read completely because Mr. Poettering said "this is not actionable, give a proposal", so I pasted the thing he decided to ignore in original ticket, and got ignored. Not even "pull requests welcome" (which I'd be fine with, I just wanted confirmation that the feature like that won't be rejected if I start writing it).
There is also issue of journald disk format being utter piece of garbage ("go thru entire journal just to get app's last few lines bad", hundreds of disk reads on simple systemctl status <appname> bad) that is consistently ignored thru many tickets from different people.
Or the issue that resolvconf replacement in systemd will just roll a dice on DNS ordering, but hey, Mr. Lennart doesn't use openvpn so it's not real issue ( https://github.com/systemd/systemd/issues/27543 )
I'm not writing it to shit on systemd and praise what was before, as a piece of software it's very useful for my job as sysadmin (we literally took tens of thousands lines of fixed init scripts out because all of the features could be achieved in unit files) and I mean "saved tons of time and few demons running" in some cases, but Mr. Poettering is showing same ignorant "I know better" attitude he got scolded at by kernel maintainers.
> Pulseaudio also completely denies existence of people trying to do music on Linux, there is no real way to make latency on it be good.
I don't care much about PA at this point tbh and don't know much about the inner workings; it always worked just fine for me. But from what I read from people more "in the know" at the time, I'd heard that a lot of the (very real) user-facing problems with PA were ultimately caused by driver and other low-level problems. Those were hacky, had poor assumptions, etc. PA ultimately exposed those failures, and largely got better over time because those problems got fixed upstream of PA.
My takeaway from what I read was basically that PA had to stumble and walk so that pipewire could run.
> For example systemd have no real method to tell it "turn off all apps after 5 minutes regardless of what silly package maintainers think". Now what happens if you have a server on UPS that have say 5 minutes of battery and one of the apps have some problem and doesn't want to close?
Add a TimeoutStopSec= to /etc/systemd/system/service.d/my-killing-dropin.conf more or less, I think? These are documented in the systemd.service and systemd.unit manpages respectively.
> Same problem also surfaced if you have say app with a bug that prevented it from closing from sigterm and you wanted to reboot a machine. Completely stuck
See the --force option on the halt, poweroff, and reboot subcommands of systemctl. The kill subcommand if you want to target that specific service.
> so I pasted the thing he decided to ignore in original ticket, and got ignored. Not even "pull requests welcome" (which I'd be fine with, I just wanted confirmation that the feature like that won't be rejected if I start writing it).
I'm certainly sympathetic to this pain point. I'd take Lennart at his word that he's not opposed. Generally speaking, from following the systemd project somewhat, it's a very busy project and it's hard for all issues to get serviced. But they're very open to PRs, generally speaking.
> Or the issue that resolvconf replacement in systemd will just roll a dice on DNS ordering, but hey, Mr. Lennart doesn't use openvpn so it's not real issue ( https://github.com/systemd/systemd/issues/27543 )
Quickly taking a peek here (and speaking as a relatively superficial user of resolved myself), isn't the proposed solution to define interface ordering?
> it will ask on all links in parallel if there's no better routing info available. In your case there is none (i.e. no ~. listed among your network interfaces), hence it will be asked on all interfaces at the same time.
It's baffling to me that anyone can imagine pipewire has been created from scratch without any lessons learned from pulseaudio and the previous issues the audio stack on linux had, and solved, over the years. Nothing is happening in a clean room bubble, every new project stands on the shoulders of giants...
LP is the Thomas Midgley Jr of Computer Science.
I thought he had proven that he leaves before the project is complete and functioning according to all the promises made.
agent Smith, the one that don't care at all about conforming to POSIX?
"In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!" -- https://archive.fosdem.org/2011/interview/lennart-poettering...
Poettering gas a track record of recognizing good ideas from Apple, then implementing them poorly. He also has a track record of closing bug reports for plain and simple bugs in his software to protect his own ego, and this kind of mentality isn't a great basis for security sensitive software.
Audio server for linux: Great idea! Pulseaudio: Genuinely a terrible implementation of it, Pipewire is a drop in replacement that actually works.
Launchd but for Linux: Great idea! SystemD: generally works now at least, but packed with insane defaults and every time this is brought up with the devs they say its the distro packagers jobs to wipe SystemD's ass and clean up the mess before users see it.
Security bug in SystemD when the user has a digit in their username: Lennart closes the bug and says that SystemD is perfect, the distros erred by permitting such usernames. Insane ego-driven response.
He really will just close a ticket because he disagrees with how Linux works. I read about systemd sysusers and thought they would be neat for running containerized services. But Poettering doesn't like the /etc/subuid files and refuses to work with them.
Well, he specifically doens't like the static allocation of subuids. There is a reason `systemd-nsresourced` exists.
How do I have nsresourced work in a regular systemd service or quadlet so that I can have an ephemeral user run a container? I am trying to find information and just seeing it as part of nsspawn, that seems to require a container specifically built around a root filesystem.
I am not going to struggle with systemd if I have to build containers specifically for it. If I have to rearrange everything I am doing I would just learn to do it on a minimal Kubernetes install instead.
nspawn containers aren't really any different to regular system images/archives other than they don't need a kernel.
I don't think the setting is exposed to regular service units (it might be able to in the future, I don't know) and I don't think podman has any integration with it.
What kinda service do you have where you need a full range of UIDs?
I don't need a full range. I would just like to run podman under a non-root user using regular system services. Especially where a persistent volume or bind mount is involved.
Let's say Home Assistant. It would be nice to have a have some system user "homeassistant" with no home directory that owns the process and owns its /var/whereever/config.conf . It would be nice to have the isolation on host in addition to the isolation via container. But I don't want to be rebuilding any containers to get that, unless I am misunderstanding something on nsresourced.
I'd be really pleased with that setup. MQTT could be its own system user. And HA could depend on MQTT so I have nice startup behavior. Etc.
IDK how to have system users like this run a container without the subuid range. Even when I create the users with ranges in the file, there seems to be problems with informing systemd (as a non-root user) that the running process is different from the one it started.
podman quadlet doesn't seem to support running at a "system level" as a non-root user, at least according to their docs[0]. I assume they make some assumptions which wouldn't hold up if the user actually changed when running at a system level, dunno.
> But I don't want to be rebuilding any containers to get that, unless I am misunderstanding something on nsresourced.
Setting up the user namespace would be part of the container manager and not the containers themselves, so they shouldn't need any rebuilding or special handling (possibly the files might need to be shifted into the "foreign ID" range[1, 2], but I might be lying with this and this isn't necessary for this usecase) but the container manager needs to be specifically make use of nsresourced.
I really think currently the best option is to go with either systemd as your "container manager" (e.g. just regular system files with sandboxing or nspawn images or maybe systemd-portabled[3]) or podman as your container manager. As much as I too would love to mix them, I don't think it's the best idea (at least in the current state) and just go with what is more suited for the task (in your case it sounds like podman would be the most suited option).
> there seems to be problems with informing systemd (as a non-root user) that the running process is different from the one it started.
Yea, I don't think systemd likes double forking. The best option would be to keep the process that spawned your actual process alive until the child exists and just bubble up the exit code. There is the `PIDFile=` option with `Type=forking`, but I haven't used it, nor looked much into it.
[0]: https://docs.podman.io/en/v5.7.1/markdown/podman-systemd.uni...
[1]: https://www.freedesktop.org/software/systemd/man/latest/syst...
[2]: https://systemd.io/UIDS-GIDS/#special-systemd-uid-ranges
[3]: https://systemd.io/PORTABLE_SERVICES/
"At long last, we have created the Torment Nexus from classic sci-fi novel Don't Create The Torment Nexus."
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.
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.
here is some actual security: encrypted /boot, encrypted everything other than the boot loader (grub in this case)
sign grub with your own keys (some motherboards let you to do so). don't let random things signed by microsoft to boot (it defeats the whole point)
so you have grub in an efi partition, it passes secure boot, loads, and attempts to unlock a luks partition with the user provided passphrase. if it passed secure boot it should increase confidence that you are typing you password into the legit thing
so anyway, after unlocking luks, it locates the kernel and initrd inside it, and boots
https://wiki.archlinux.org/title/GRUB#Encrypted_/boot
the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech
however, this is still better than, at failure, letting anything run
sophisticated attackers will defeat this, but they can also add a variety of attacks at hardware level
I’d much rather have tamper detection. Encryption is great should the device is stolen but it feels like the wrong tool for defending against evil maids. All I’d want is that any time you open the case or touch the cold external ports (ie unbolted) you have to re-authenticate with a master password. I’m happy to use cabled peripherals to achieve this.
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.
Encryption is just a baseline. Nobody should have unencrypted personal computers.
You can have both full disk encryption AND a tamper protection!
Sorry, I wasn’t clear enough. We’re talking about three things here:
(1) Encryption: fast and fantastic, and a must-have for at-rest data protection.
It is vulnerable to password theft though. An attacker might insert evil code between power-on and disk-password-entry. With a locked down BIOS / UEFI, the only way to insert the code is to take the boot drive out of the device, modify it, put it back, and hope no one notices. “Noticing” in this case is done by either:
(2) Trust chaining: verify the signatures of the entire boot process to detect evil code.
(3) Tamper detection: verify the physical integrity of the device.
My point is that (1) is a given, and out of (2) or (3), I’d rather have the latter than deal with the shoddiness of the former
> the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech
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...
Doing secure boot properly is kind of difficult. There are a bunch of TPM measurement registers for various bits and bobs (kernel, initramfs, cmdline, lots more). Using UKIs simplifies it a lot, but it’s not trivial to do right at the moment.
Secure Boot and TPM are separate things. The current Secure Boot policy gets measured by the TPM but that's about it.
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".
Just because OpenSSL had a CVE posted about today, that didn't mean we should go back to use HTTP for the web.
It does mean we should recognize that SSL is nice for some basic privacy/security, but not perfect security.
Same with remote attestation. Not all implementations are actually secure. But hopefully over time those security bugs can be ironed out and the cost to extract a key be made infeasable.
Hopefully not. What you have just said is a synonym for "But hopefully over time manufacturers will be able to completely prevent users from running unapproved software."
In the case of video game consoles that could be the case. It turned out that being able to run unapproved software results mainly in people playing pirated games. These security measures are reactive to the actions other people have taken. We already experimented with computing being the wild west where there was little to no security. It turned out that bad actors will abuse anything they can find. Even if it's not economical some attackers will still cause abuse.
There's always going to be a market for computers that can run unapproved software. I don't see that going away.
Huh? Why should people who pay for the hardware not be able to run whatever they want? Why include them as ‘attackers’?
Shareholders über alles?
There is the integrity measurement architecture but it isn't very mature in my opinion. Even secureboot and module signing is a manual setup by users, it isn't supported by default, or by installers. You have to more or less manage your own certs and CA, although I did notice some laptops have debian signing keys in UEFI by default? If only the debian installer setup module signing.
But you miss a critical part - Secure Boot, as the name implies is for boot, not OS runtime. Linux I suppose considers the part after initrd load, post-boot perhaps?
I think pid-1 hash verification from the kernel is not a huge ask, as part of secure boot, and leave it to the init system to implement or not implement user-space executable/script signature enforcement. I'm sure Mr. Poettering wouldn't mind.
It is not useless. I'm using UKI, so initrd is built into the kernel binary and signed. I'm not using bootloader, so UEFI checks my kernel signature. My userspace is encrypted and key is stored in TPM, so the whole boot chain is verified.
you can merge the initrd + kernel into one signed binary pretty easily with systemd-boot
add luks root, then it's not that bad
Yes, you can. I really don't want to be in the business of building OSes. If these guys make it so that getting reasonable boot security is a simple toggle, I'd be grateful.
On arch it isn't particularly difficult to create UKIs other than changing like 2 lines in `mkinitcpio`'s config.
Then there is also `ukify` by systemd which also can create UKIs, which then can be installed with `kernel-install`, but that is a bit more work to set up than for `mkinitcpio`.
The main part is the signing, which I usually have `sbctl` handle.
Isn’t the idea that the kernel will verify anything beneath it. Secure boot verifies the kernel and then it’s in the hands of the kernel to keep verifying or not.
> the kernel will verify anything beneath it
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.
Standardizing that approach is one thing that the systemd project has been working on. They've built various components to help with that, including writing specifications (via the UAPI group) on how that should all fit together.
ParticleOS[0] gives a look at how this can all fit together, in case you want to see some of it in action.
[0] https://github.com/systemd/particleos
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?
Opensuse have been working on making secure boot/TPM FDE unlock easy to use for a while now. https://news.opensuse.org/2025/11/13/tw-grub2-bls/
> 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.
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.
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.
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.
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.
> you cannot use unsigned drivers because the kernel can detect and activate the lockdown mode
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).
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)
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.
Remote attestation seems more useful for server hosts to let VPS users verify the server hasn’t been tampered with.
YOU can use remote attestation to verify a remote server you are paying for hasn't been tampered with.
This happens much less frequently than the manufacturer of "my" computing device verifies that I haven't tampered with it. On net, it's a wholesale destruction of user freedom.
"it's a wholesale destruction of user freedom." This is ridiculously hyperbolic language for what are basically fancy digital signatures. There is nothing stopping you from using two different systems, one that passes attestation and one that doesn't.
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.
The better question then is why the actual f** can an OTA firmware update touch anything in the steering or powertrain of the car, or why do I even need a computer that's connected to anything, and one which does more than just make sure I get the right amount of fuel and spark, or why on earth do people tolerate this sort of insanity.
If a malicious update can be pushed because of some failure in the signature verification checks (which already exist), what makes you think the threat actor won’t have access to signing keys?
This is not what attestation is even seeking to solve.
Firmware upgrades don't need to use the same protocols. Without secure boot any applet can take a security hole escalate and persist until you take a trip to a zone of interest. With secure-boot+attestation, the vendors can choose not to let you download the latest map data, report you to the authorities, etc.
Why do people take DA as "Hail Satan" anyways.
“With secure-boot+attestation, the vendors can choose not to let you download the latest map data, report you to the authorities”
As far as I'm concerned, you just conceded the argument.
If this was about stopping malware, it wouldn’t be targeting Linux endpoints.
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.
There is. Signal uses it, for example. https://signal.org/blog/building-faster-oram/
For another example, IntegriCloud: https://secure.integricloud.com/
confidential computing?
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?
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.
> 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.
On the other side, Mulvad is looking at remote attestation so that the users can verify their servers: https://news.ycombinator.com/item?id=29903695
> * 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.
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.
Banks do this because they have made their own requirement that the mobile device is a trust root that can authenticate the user. There are better, limited-purpose devices that can do this, but they are not popular/ubiquitous like smartphones, so here we are.
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.
Banks do this because they can. If most consumer devices did not support the tech they would not be able to.
Then work with the bank to prove the signer is trustworthy.
> 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.
“buggy”
Don't get me wrong, I'm happy to attribute a lot of malice to Microsoft, but in this case I really do believe that it was incompetence. Everything I've ever read about 90%+ of hardware vendors is that shipping hilariously broken firmware is an everyday occurrence for them.
(This is separate from Windows RT, of course)
This reminds me of when I enrolled only my own keys into a gigabyte AB350 and I just soft-bricked it because presumably some opt-rom required MS keys.
I exchanged it for an Asrock board and there I can enable secure boot without MS keys and still have it boot cuz they actually let you choose what level of signing the opt-rom needs when you enable secure boot.
What I want to say with this is that it requires the company to actually care to provide a good experience.
> 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.
Phones don't implement UEFI.
Most don't, but they're usually equivalently locked down nevertheless.
UEFI on x86_64 and phones are not comparable when it comes to being "locked down".
Are you sure?
Note that the comment you replied to does not even mention phones. Locked down Secure Boot on UEFI is not uncommon on mobile platforms, such as x86-64 tablets.
What about all those Windows on ARM laptops?
I wish the myth of the spec would die at this point.
Many motherboards secure boot implimentation violates the supposed standard and does not allow you to invalidate the pre-loaded keys you don't approve of.
Well, I can see what heinous thing is going to be ruining my day in 5 years.
Attestation, the thing we're going to be spending the next forever trying to get out of phones, now in your kernel.
It's interesting how quickly the OSS movement went from "No, no, we just want to include companies in the Free Software Movement" to "Oh, don't worry, it's ok if companies with shareholders that are not accountable to the community have a complete monopoly on OSS, and decide what direction it takes"
FOSS was imagined as a brotherhood of hackers, sharing code back and forth to build a utopian code commons that provided freedom to build anything. It stayed firmly in the realm of the imaginary because, in the real world, everybody wants somebody else to foot the bill or do the work. Corporations stepped up once they figured out how to profit off of FOSS and everyone else was content to free ride off of the output because it meant they didn't have to lift a finger. The people who actually do the work are naturally in the driver's seat.
This perspective is astonishingly historically ignorant, and ignores how "Open Source Software" was a deliberate political movement to simultaneously neuter the non-company-friendly goals of FOSS while simultaneously providing a competing (and politically distracting) movement that deliberately courted companies.
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.
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.
> 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.
Nobody says that you will not have alternatives. What people are saying, is that if you're using those alternatives you won't be able to watch videos online, or access your bank account.
Eventually you will not be able to block ads.
> Nobody says that you will not have alternatives
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.
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
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...
> 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
Yeah. I'm pretty sure it requires a very specific psychological profile to decide to work on such a user-hostile project while post-fact rationalizing that it's "for good".
All I can say is I'm not surprised that Poettering is involved in such a user-hostile attack on free computing.
P.S: I don't care about the downvotes, you shouldn't either.
Does this guy do anything that is user-friendly and is as per open source ethos of freedom and user control? In all this shit-show of Microsoft shoving AI down the throat of its users, I was happy to be firmly in the Linux camp for many many years. And along come these kind of people to shit on that parade too.
P.S: Upvoted you. I don't care about downvotes either.
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
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.
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
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.
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.
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.]
no no, let him get distracted by it, the one thing that happened after he got bored with pulseaudio is that pulseaudio started being better.
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.
Personally for me this is interesting because there needs to be a way where a hardware token providing an identity should interact with a device and software combination which would ensure no tampering between the user who owns the identity and the end result of computing is.
A concrete example of that is electronic ballots, which is a topic I often bump heads with the rest of HN about, where a hardware identity token (an electronic ID provided by the state) can be used to participate in official ballots, while both the citizen and the state can have some assurance that there was nothing interceding between them in a malicious way.
Does that make sense?
No.
Why not? Being terse does not make one right...
Off the top of my head, because
- You're just moving your trust elsewhere, this time to a private corporation (whoever makes the CPU / TPM / other "trusted" component).
- This doesn't guarantee voter anonymity the way paper ballots do. Considering the analog hole and the complexity of computers, I can think of a billion ways a motivated and resourceful Mallory could to connect someone to their ballot.
> This doesn't guarantee voter anonymity the way paper ballots do.
You're saying that with a lot of assurance, but in my opinion that's still to be debated. We can build something that will keep at least a degree of separation between the identity that points to a specific individual and the identity that casts the ballot.
https://xkcd.com/2030/
Right... we should not even try because memes...
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.
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...
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.
Entities other than me being able to control what runs on the device I physically posses is absolutely not acceptable in any way. Screw your clients, screw you shareholders and screw you.
Assuming you're using systemd, you already gave up control over your system. The road to hell was already paved. Now, you would have to go out of your way to retain control.
In the great scheme of things, this period where systemd was intentionally designed and developed and funded to hurt your autonomy but seemed temporarily innocuous will be a rounding error.
Nah man, yo are FUDing. systemd might have some poor design choices and arrogant maintainers, but at least I can drop it at any time and my bank wouldn't freak out about it. This one… It's a whole another level.
I don't think Mr Pottering was brought by accident, maybe his decade of contribution making sure systemd services can be manipulated by a supervisor (in the case of wsl and ms) is a valuable asset. Systemd don't even need to change much to become the devil itself, it just have to upstream merge changes already consolidated in the past 5 years or so... But logically it's safe because for this to become a problem systemd would have to be adopted by the majority of distributions and its maintainers would have to concede to the pressure of big corps and such...oh, wait
Do you plan to sell this technology to laptop makers so their laptops will only run the OS they came with?
Or, worse, run any unsupported linux as long as it contains systemd, so no *bsd, etc, and also no manufacturer support?
Laptops already ship secure boot.
Not all. The ones that ship Linux preinstalled and with support don't.
I hope you are mistaken. It's embarrassing how far behind in security the desktop Linux ecosystem is.
Agreed in general. But regarding secure boot, it's not like shim actually helps with real security either afaiu, right?
AFAIU (I haven't looked much into it) shim basically exists so that MS signs the shim once (or only a few times when updated), which has the distro public key embedded, which does further verification of the chain (bootloader/kernel) which gets updated more frequently.
That's basically my understanding too. But since you can still boot any shim-supported distro, Secure Boot + shim practically gains you nothing. An adversary can simply boot their own own copy of shim with whatever OS they like.
> An adversary can simply boot their own own copy of shim with whatever OS they like.
They'd need to get MS to sign it first, but otherwise yea. That's why I remove the MS keys on my non-windows systems.
I don't know all the ins and outs, but because of the Machine Owner Key (MOK) mechanism in shim, it should be possible to boot arbitrary OSes without MS signing anything.
Your step of removing the MS keys works of course :) Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS. Also I think that firmware updates can be problematic?
> Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS
Yea, I bricked a Gigabyte board and still haven't been able to fix it. I just replaced it with an Asrock board and that has settings for what to do with option-rom when secureboot is enabled (always execute, always deny, allow execute, defer execute, deny execute and query user) and I have no clue what half of them specifically do (like, does "allow execute" only execute if a matching key exists and doesn't execute if it doesn't? and what is the difference between "always deny" and "deny execute"? and defer to when??). But I just set it to always execute and my problem is solved.
I believe you are confusing security with freedom and "behind" with "advanced".
They have a TPM that you can enable and add your own keys if you want to.
For now.
I can turn that crap off. For now.
Do you really think Laptop makers would buy a whole company to figure out how to remove that option?
If they wanted to do that, they already would have. Do you think laptop makers need this technology to limit user freedom this way?
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.
The motivation is nice. The idea has merit.
It's the people behind this project who scare me.
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.
If you're going to flame it you might as well point out something concrete you don't like about it.
"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."
See Android; or, where you no longer own your device, and if the company decides, you no longer own your data or access to it.
https://0pointer.net/blog/authenticated-boot-and-disk-encryp...
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.
... and it will also refuse to boot if it has been modified by the user.
Preventing this was the reason we had free software in the first place.
Increasing security for the system owner will necessarily decrease the ability of others to modify the system in ways the owner doesn't like.
With "owner" not being the legal owner, but Microsoft.
And if Linux$oft suddenly decides every user's system needs a backdoor or that every system mus automatically phone home with your entire browsing data, then, well, too bad, so sad of course!
Jesus.
Unless you're one of the 0.00000000001% of humans using a farm-to-table laptop with coreboot, what's stopping that from happening today?
How exactly would this happen.
I mentioned it somewhere else in the thread, and btw, I'm not affiliated with the company, this is just my charitable interpretation of their intentions: this is not for requiring _every_ consumer linux device to have attestation, but for specific devices that are needed for niche purposes to have a method to use an open OS stack while being capable of attestation.
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.
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.
> 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.
> Where/who have you received funding from
I don't think you will ever get a response to that
It's pretty normal to say who leads your investing rounds is it not?
I'm not asking for a client list, to be clear.
I agree with you - but considering what they want to implement and what it can be used for there are probably investors that might not want to be outed (this early). Kinda paranoid I admit, but history has shown that stuff like this WILL be misused.
>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.
Remote attestation requires a great deal of trust... I know this comment is likely to be down-voted, but I can't think of a Lennart Poettering project that didn't try to extend, centralize, and conglomerate Linux with disastrous results in the short term; and less innovation, flexibility, and functionality in the long term. Trading the strength of Unix systems for goal of making them more "Microsoft" like.
Remote attestation requires a great deal of trust, and I simply don't have it when it comes to this leadership team.
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/
Also see http://amutable.com/events which lists a talk at Open Confidential Computing Conference (Berlin, March)
I don't even know why these kind of user-hostile people are given a platform. This kind of shit is against freedom and user control.
"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?
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.
> If you try to install a different operating system, your computer will not boot.
That does not follow. That would only very specifically happen when all of these are true:
1. Secure Boot cannot be disabled
2. You cannot provision your own Secure Boot keys
3. Your desired operating system is not signed by the computer's trusted Secure Boot keys
"Starting in a verified state and stay[ing] trusted over time" sounds more like using measured boot. Which is basically its own thing and most certainly does not preclude booting whatever OS you choose.
Although if your comment was meant in a cynical way rather than approaching things technically, than I don't think my reply helps much.
https://youtu.be/EzSkU3Oecuw?si=1fNV6XkyTv7SfpJs
Good thing, without the power coming from RedHat money, the capacity of ruining the Linux ecosystem will finally be reduced!
This feels like something that's being created for a Microsoft edition of Linux.
Microsoft has fully embraced Linyx now, it's time to move to the next step.
Everything under the assumption that tampering is a bigger problem then abusive companies controlling your software stack.
Why on earth would somebody make a company with one of the the most reviled programmers on earth? Everyone knows that everything he touches turns to shit.
How do you plan handle the confused deputy problem?[1]
[1] https://en.wikipedia.org/wiki/Confused_deputy_problem
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 this question, it perfectly captures something that I believe many would like answered.
As someone who's lost many hours troubleshooting systemd failures, I would like an answer to this question, too.
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.
"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.
I had a situation like that with an undocumented behavior and systemd-tmpfiles. I wanted it to clean up a directory in /var/tmp/ occasionally. The automation using that directory kept breaking, however, because instead of either finding a whole intact git repo to update or a deleted repo, it instead found only a scattering of files that were root-owned with read-only permissions. There was yet another undocumented feature in systemd-tmpfiles where it would ignore root-owned, read-only files regardless of explicit configuration telling it to clean up the contents of those directories. Eventually this feature was quietly removed:
https://bugzilla.redhat.com/show_bug.cgi?id=1780979
https://github.com/systemd/systemd/commit/a083b4875e8dec5ce5...
That was far from the only time that the systemd developers decided to just break norms or do weird things because they felt like it, and then poorly communicate that change. Change itself is fine, it's how we progress. But part of that arrogance that you mentioned was always framing people who didn't like capricious or poorly communicated changes as being against progress, and that's always been the most annoying part of the whole thing.
Speaking of systemd-tmpfiles, wasn't there an issue where asking it to clean all temp files would also rm -rf /home and this was closed as wontfix, intended behavior?
https://linuxiac.com/systemd-tmpfiles-issue/
> 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?
Your distribution has configured your GDM or Getty to have some dependency on something that ultimately waits on dhcpcd/network-online.target.
It’s not really the fault of systemd; it just enables new possibilities that were previously difficult/impossible and now the usage of said possibilities is surfacing problems.
It is the fault of systemd that there's no interactive control.
On other inits, I can hit ctrl-C to break out of a poorly configured setup. Yes, it's more difficult when there's potentially parallelism. But systemd is not uniformly better than everything else when it lacks interactivity.
And it might not be better than everything else if common distributions set it up wrong because it's difficult to set it up right. If we're willing to discount problems related to one init system because the distribution is holding it wrong, then why don't we blame problems with other init systems on distributions or applications, too? There's no need to restart crashing applications if applications don't crash, etc.
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.
And "because I want to" is a legitimate reason, if it's my system. It's not up for discussion.
And Void Linux. And Gentoo. And Alpine Linux. And Slackware. And others.
After over a decade of Debian, when I upgraded my PC, I tried every big systemd-based distro, including opensuse, which I wholly loathed. I finally decided on Void and feel at home as I did 20+ years ago when I began.
There are serious problems with the systemd paradigm, most of which I couldn't argue for or against. But at least in Void, I can remove network-manger altogether, use cron as I always have, and generally remain free to do as I please until eventually every package there is has systemd dependencies which seems frightfully plausible at this pace.
Void is as good as I could have wanted. If that ever goes, I guess it's either BSD or a cave somewhere.
I'm glad to see the terse questions here. They're well warranted.
How is systemd stopping you use cron?
Not stopping. Just clashing with that and a hundred other things that I never wanted managed by one guy. Systemd.timer, systemd.service, yes, trivial, but I don't catalog every thing that bothers me about systemd - I just stay away from it. There are plenty of better examples. So where ever I wrote 'stop', it should read hinder.
systemd parses your crontab and runs the jobs inside on its own terms
of course you can run Cron as well and run all your jobs twice in two different ways, but that's only pedantically possible as it's a completely useless way to do things.
> systemd parses your crontab and runs the jobs inside on its own terms
systemd itself only has 2 references to "crontab" in its entire codebase and both of those are in man-pages.
My educated guess is that some other package is installing a generator to generate systemd units out of the crontab (e.g. https://github.com/systemd-cron/systemd-cron)
> Void is as good as I could have wanted. If that ever goes, I guess it's either BSD or a cave somewhere.
If systemd-less Linux ever go, there are indeed still the BSDs. But I thought long and hard about this and already did some testing: I used to run Xen back in the early hardware-virt days and nowadays I run Proxmox (still, sadly, systemd-based).
An hypervisor with a VM and GPU passthrough to the VM is at least something too: it's going to be a long long while before people who want to take our ability to control our machines will be able to prevent us from running a minimal hypervisor and then the "real" OS in a VM controlled by the hypervisor.
I did GPU passthrough tests and everything works just fine: be it Linux guests (which I use) or Windows guests (which I don't use).
My "path" to dodge the cave you're talking about is going to involved an hypervisor (atm I'm looking at the FreeBSD's bhyve hypervisor) and then a VM running systemd-less Linux.
And seen that, today, we can run just about every old system under the sun in a VM, I take we'll all be long dead before evil people manage to prevent us from running the Linux we want, the way we want.
You're not alone. And we're not alone.
I simply cannot stand the insufferable arrogance of Agent Poettering. Especially not seen the kitchen sink that systemd is (systemd ain't exactly a homerun and many are realizing that fact now).
Gentoo doesn't "exist" because it is necessary to have an alternative to systemd. Gentoo is simply about choice and works with both openrc and systemd. It supported other inits to some degree as well im the past.
Systemd has recently added experimental support for musl libc, which should eventually allow Alpine to upgrade though
If they want to. Alpine is minimal. systemd is anything but. It's like the GNOME of inits.
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.
Quadlet actually solves this. It's the newer way to define containers for systemd and handles the rootless user case properly. I migrated my services to it recently and it's much more robust than the old generate scripts.
Could you give an example system-level quadlet that accepts connections on a low port, like 80, but runs the actual container as a non-root user (and plays nice with systemd, no force kill after timeout to stop, no reporting as failed for a successful stop)?
My understanding is quadlet does not solve this, and my options are calling "systemctl --user" or "--userns auto". I would love to be wrong here.
As an alternative solution to the sibling comment, I do run everything rootless in systemd --user so my services don't have access to privileged ports, and use firewall rules to redirect the external interface low ports, to the local high ports (that sounds annoying but in practice I only redirect a single port - 443 - to traefik and the use it to route to the right container service depending on domain)
I solved the port 80 issue by adding AmbientCapabilities=CAP_NET_BIND_SERVICE to the Service section of the unit file. That lets you bind privileged ports while still defining a User= line to run non-root. The lifecycle management seems solid in my experience, no force kills required.
Well, thank you, I will give it a try
Quadlet are great but running podman via systemd as a non root user worked perfectly well before quadlets and I have no idea what your parent is talking about (I'm currently in the process of converting my home services from rootless podman over systemd to quadlet)
Fair, it worked, but podman generate systemd is deprecated now. I found the generated unit files pretty brittle to maintain compared to just having a declarative config that handles the lifecycle.
I agree 100%, I was stuck without quadlet in previous Debian stable so I had to work with systemd generate, but quadlets are undoubtedly better, and I was looking forward to upgrade Debian just for that, and now that I did, I'm really happy to migrate. Especially custom container image management is so much smoother.
> 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.
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.
I'd be interested in what other init alternatives offer the security options systemd does
> in every way
You realize that quite a few senior and experienced developers and devops engineers do not share this view, right?
It doesn't smell like DRM, it is literally DRM.
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.
Awful. I hope they fall.
anything that keeps him away from systemd is a good thing.
systemd kept him away from pulseaudio and whoever is/was maintaining that after him was doing a good job of fixing it.
The ultimate fix was to throw it out and replace it. Pipewire is a so much better system.
I'll ask the dumb question sorry!
Who is this for / what problem does it solve?
I guess security? Or maybe reproducability?
My guess the problem being solved is how to get acquired by a big Linux vendor.
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.
[dead]
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.
it's not just a resolver, log system, etc
it's a buggy-as-hell resolver, buggy-as-hell log system, buggy-as-hell ntp client, buggy-as-hell network manager, ...
All vague hand waving at this point and not much to talk about. We'll have to wait and see what they deliver, how it works and the business model to judge how useful it will be.
What might you call a sort of Dunbar's number that counts not social links, but rather the number of things to which a person must actively refuse consent to?
What will they be reinventing from scratch for no reason?
Can someone smarter than myself describe immutability versus atomicity in regards to current operating systems on the market?
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.
Hopefully he will leave systemd alone and stop closing bugs he doesn't understand now
[dead]
The first steps look similar to secure boot with TPM.
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/
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.
The events includes a conference title "Remote Attestation of Imutable Operating Systems built on systemd", which is a bit of a clue.
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.
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.
That'd be too bad. Sometimes, I feel like the general public doesn't deserve general purpose computing.
Only by creating a new stalemate between essential liberty and a little temporary security — anticheat doesn't protect you from DMA cheating.
I might be behind on the latest counter-counter-counter-measures, but I know some of the leading AC solutions are already using IOMMU to wedge a firewall between passive DMA sniffers and the game processes memory.
e.g. https://support.faceit.com/hc/en-us/articles/19590307650588-...
I think they use hardware IDs of devices with IOMMU-incompatible drivers.
I love the gall
> IOMMU is a powerful hardware security feature, which is used to protect your machine from malicious software
The ring-0 anticheat IS that fucking malicious software
> resolve the Linux gaming vs. anti-cheat stalemate
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?
I would rather have it unresolved forever.
I sincerely hope not.
Verifiable to who? Some remote third party that isn't me? The hell would I want that?
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.
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.
Propaganda begins with reframing. What russia is waging is not a war, it's a special military operation. War is peace. Data on Windows is secure. Linux's security is far behind.
That sort of things.
What are you talking about? This has nothing to do with general purpose computing and everything to do with allowing you to authenticate the parts of the Linux boot process that must by necessity be left unencrypted in order to actually boot your computer. This is putting SecureBoot and the TPM to work for your benefit.
It's not propaganda in any sense, it's recognizing that Linux is behind the state of the art compared to Windows/macOS when it comes to preventing tampering with your OS install. It's not saying you should use Windows, it's saying we should improve the Linux boot process to be a tight security-wise as the Windows boot process along with a long explanation of how we get there.
Secure boot is initialized by the first person who physically touches the computer and wants to initialize it. Guess who that is? Hint: it's not the final owner.
It's only secure from evil maker attacks if it can be wiped and reinitialised at any time.
You seem to be under the impression that you cannot reset your Secure Boot to setup mode. You can in the UEFI, doing so wipes any enrolled keys. This, of course assumes you trust the UEFI (and hardware) vendors. But if you don't, you have much bigger problems anyway.
Is it possible someone will eventually build a system that doesn't allow this? Yes. Is this influenced in any way by features of Linux software? No.
It is certainly influenced by the features of Linux software. If Linux does not support this then this preserves a platform as an escape route where this is not possible and this substantially reduces the incentive to provide certain content and services (!) only when this is enabled.
> allowing you to authenticate the parts of the Linux boot
No, not you. Someone else for you. And that's the scary part.
Yes you. The parts being expanded upon happen after the shim is authenticated by SecureBoot and are fully in your control. The scary part has already happened, Linux distros support SecureBoot right now and have for a while. Right now the current state of the Linux boot process is all the downsides (in your view) of SecureBoot with none of the upsides because very little is authenticated after that.
It's temporary.
In a few years running random code on your computer would be seen a bit unethical.
> we should improve the Linux boot process to be a tight security-wise as the Windows
I hope this never happens. I really want my data secure and I do have something to hide. So, no Microsoft keys on my computer and only I will decide what kind of software I get to run.
Absolutely fuck that.
Security is fine, if you can reset the keys at any time.
If.
So to I guess spite Microsoft or something you're going to make your data less secure?
Turning off SecureBoot only means any rando can decide what software runs on your device and install a bootkit. Not authenticating the rest of the boot process as outlined here (what Microsoft calls Trusted Boot) only means that randos can tamper with your OS using the bits that can't be encrypted.
Literally an own-goal in every sense of the word.
> Turning off SecureBoot only means any rando can decide what software runs on your device
I see it as exactly the opposite: turning SecureBoot on means someone else can and will decide what software runs on my device.
> spite Microsoft or something you're going to make your data less secure
We all know very well Microsoft's track record with security and with data protection measures and practice. Trusting Microsoft is... irrational, let's put it that way.
> Microsoft
the guys that copy your bitlocker keys in the clear
Considering that (for example) your data on ChromeOS is automatically copied to a server run by Google, who are legally compelled to provide a copy to the government when subject to a FISA order, it is unclear what Poettering's threat model is here. Handwringing about secure boot is ludicrous when somebody already has a remote backdoor, which all of the cited operating systems do. Frankly, the assertion of such a naked counterfactual says a lot more about Poettering than it does about Linux security.
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.
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.)
...and the moon.
You'll understand if I don't think the tradeoffs were necessary, or worthwhile.
Ambition does really weird things to people.
But I'm sure in this case when they achieve some kind of dominant position and Microsoft offers to re-absorb them they will do the honorable thing.
When has that ever happened in the entire human history?
People do the honorable thing all the time.
These people don't, but people you've never heard of are always doing honorable things.
Might be some sort of connection there.
Yes, I have.
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.
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.
We all know who controls the keys. It's the first party who puts their hands on the device.
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.
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.
Just to make it clear - on Android you don't have the keys. Even with avb_custom_key you can't modify many partitions.
None of the consumer mobile devices give you all the keys. There are many reasons for that, but 99.9% of them are monetary reasons.
But I want to buy that kind of device for money and I can't.. something is wrong with the market, looks like collusion..
> who controls the keys
Not you. This technology is not being built for you.
> 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?
"cryptographically verifiable integrity" is a euphemism for tivoization/Treacherous Computing. See, e.g., https://www.gnu.org/philosophy/can-you-trust.en.html
As the immediate responder to this comment, I claim to be the next guy. I love systemd.
I don't like few pieces and Mr. Lennarts attitude to some bugs/obvious flaws, but by far much better than old sysv or really any alternative we have.
Doing complex flows like "run app to load keys from remote server to unlock encrypted partition" is far easier under systemd and it have dependency system robust enough to trigger that mount automatically if app needing it starts
Remote attestation is literally a form of DRM
There are genuine positive applications for remote attestation. E.g., if you maintain a set of servers, you can verify that it runs the software it should be running (the software is not compromised). Or if you are running something similar to Apple's Private Compute Cloud to run models, users can verify that it is running the privacy-preserving image that it is claiming to be running.
There are also bad forms of remote attestation (like Google's variant that helps them let banks block you if you are running an alt-os). Those suck and should be rejected.
Edit: bri3d described what I mean better here: https://news.ycombinator.com/item?id=46785123
I agree that DRM feels good when you're the one controlling it.
> There are genuine positive applications for remote attestation
No doubt. Fully agree with you on that. However Intel ME will make sure no system is truly secure and server vendors do add their mandatory own backdoors on top of that (iLO for HP, etc).
Having said that, we must face the reality: this is not being built for you to secure your servers.
> Remote attestation is literally a form of DRM
Let's say I accept this statement.
What makes you think trusted boot == remote attestation?
Trusted boot is literally a form of DRM. A different one than remote attestation.
> Trusted boot is literally a form of DRM. A different one than remote attestation.
No, it's not. (And for that matter, neither is remote attestation)
You're conflating the technology with the use.
I believe that you have only thought about these technologies as they pertain to DRM, now I'm here to tell you there are other valid use cases.
Or maybe your definition of "DRM" is so broad that it includes me setting up my own trusted boot chain on my own hardware? I don't really think that's a productive definition.
It's possible to not implement remote attestation even when you implement secure boot.
This company is explicitly all about implementing remote attestation (which is a form of DRM):
https://amutable.com/events
> Remote Attestation of Imutable Operating Systems built on systemd
> Lennart Poettering
> This company is explicitly all about implementing remote attestation (which is a form of DRM):
Is there a HN full moon out?
Again, this is wrong.
DRM is a policy.
Remote attestation is a technology.
You can use remote attestation to implement DRM.
You can also use remote attestation to implement other things.
there are no other things. The entire point of remote attestation is to manage(i.e. take away) rights of user that runs it, unless you own entire chain, which you do not on any customer device
[dead]
Secure boot and attestation both generally require a form of DRM. It’s a boon for security, but also for control.
> Secure boot and attestation both generally require a form of DRM.
They literally don't.
For a decade, I worked on secure boot & attestation for a device that was both:
- firmware updatable - had zero concept or hardware that connected it to anything that could remotely be called a network
Interesting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source?
> Interesting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source?
The update is predicated on a valid signature.
So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.
> So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.
Would love to hear more of your thoughts on how the users of the device I worked on had their freedom restricted!
I guess my company, the user of the device that I worked on, was being harmed by my company, the creator of the device that I worked on. It's too bad that my company chose to restrict the user's freedom in this way.
Who cares if the application of the device was an industrial control scenario where errors are practically guaranteed to result in the loss of human life, and as a result are incredibly high value targets ala Stuxnet.
No, the users rights to run any code trumps everything! Commercial device or not, ever sold outside of the company or not, terrorist firmware update or not - this right shall not be infringed.
I now recognize I have committed a great sin, and hope you will forgive me.
I don't mind SystemD.
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.
No, it's not "all applications of cryptography". It's only remote attestation.
Buddy, if I want encryption of my own I've got secure boot, LUKS, GPG, etc. With all of those, why would I need or even want remote attestation? The purpose of that is to assure corporations that their code is running on my computer without me being able to modify it. It's for DRM.
I am fairly confident that this company is going to assure corporations that their own code is running on their own computers (ie - to secure datacenter workloads), to allow _you_ (or auditors) to assure that only _your_ asserted code is also running on their rented computers (to secure cloud workloads), or to assure that the code running on _their_ computers is what they say it is, which is actually pretty cool since it lets you use Somebody Else's Computer with some assurance that they aren't spying on you (see: Apple Private Cloud Compute). Maybe they will also try to use this to assert "deep" embedded devices which already lock the user out, although even this seems less likely given that these devices frequently already have such systems in place.
IMO it's pretty clear that this is a server play because the only place where Linux has enough of a foothold to make client / end-user attestation financially interesting is Android, where it already exists. And to me the server play actually gives me more capabilities than I had: it lets me run my code on cloud provided machines and/or use cloud services with some level of assurance that the provider hasn't backdoored me and my systems haven't been compromised.
How can you be "pretty sure" they're going to develop precisely the technology needed to implement DRM but also will never use or allow it to be used by anybody but the lawful owners of the hardware? You can't.
It's like designing new kinds of nerve gas, "quite sure" that it will only ever be in the hands of good guys who aren't going to hurt people with it. That's powerful naïveté. Once you make it, you can't control who has it and what they use it for. There's no take-backsies, that's why it should never be created in the first place.
The technology needed to implement DRM has been there for 20+ years and has already evolved in the space where it makes sense from an "evil" standpoint (if you're on that particular side of the fence - Android client attestation), so someone implementing the flip side that might actually be useful doesn't particularly bother me. I remember the 1990s "cryptography is the weapon of evil" arguments too - it's funny how the tables have turned, but I still believe that in general these useful technologies can help people overall.
The technology already exists and also there is unmet industrial market demand for the technology. Incoherent. If it already exists as you say, then Lennart should fuck off and find something else to make.
> The technology already exists and also there is unmet industrial market demand for the technology.
The "bad" version, client attestation, is already implemented on Android, and could be implemented elsewhere but is only a parallel concept.
There is unmet industrial market demand for the (IMO) "not so bad / maybe even good" version, server attestation.
> It's like designing new kinds of nerve gas, "quite sure" that it will only ever be in the hands of good guys who aren't going to hurt people with it. That's powerful naïveté. Once you make it, you can't control who has it and what they use it for. There's no take-backsies, that's why it should never be created in the first place.
Interesting choice of analogy, to compare something with the singular purpose to destroy biological entities, to a computing technology that enforces what code is run.
Can you not see there might be positive, non-destructive applications of the latter? Are you the type of person that argues cars shouldn't exist due to their negative impacts while ignoring all the positives?
Coming from software supply chain, I am excited to see such a cracked team handle this problem and I wish we talked more about this in FOSS land.
I see the use case for servers targeted by malicious actors. A penetration test on an hardened system with secure boot and binary verification would be much harder.
For individuals, IMO the risk mostly come from software they want to run (install script or supply chain attack). So if the end user is in control of what gets signed, I don't see much benefit. Unless you force users to use an app store...
Why have the responses to the post from the CEO been moved to their own top-level posts? Also, why are replies disabled for the CEO post?
Because the feedback is overwhelmingly negative and thus deemed useless for them.
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.
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.
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?
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.
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.
> 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?
> we will never enforce using any of these features in systemd itself. It will always be up to the distro
So, plausible deniability. It's not the systemd project, it's the distro.
> I certainly don't think distributions like Fedora or Debian will ever go in that direction.
In the past they made decisions that we can call unexpected. I believe that in the short term future they won't but in say ten years? I'm not sure. The technology (created by Amutable?) will be mature by that time and ready to close Linux down.
Building stuff like this is wrong. You should find a different job.
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.
> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle
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.
> today. Of course this may change down the line.
Given Microsoft's track record I don't believe this will stay that way for long.
> 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?
Why are you buying hardware that Microsoft controls if you're concerned about this?
With TPM, Microsoft controls practically all the Intel hardware.
Nothing, but openbsd is amazing and just works. Anyone still using Linux on the desktop in 2026 should switch.
"Just don't use X" doesn't solve any problems in any space, unfortunately.
Plus, it's an avoidant and reductionist take.
Note: I have nothing against BSDs, but again, this is not the answer.
It works for me and for millions of others.
Stop trying to make everyone act like you act.
> Stop trying to make everyone act like you act.
Yeah! Telling people what to do is rude!
> Anyone still using Linux on the desktop in 2026 should switch
Oh.
I'm not trying to make everyone act like I act.
Also, I know. A few of my colleagues run {open, free, dragonfly}BSD as their daily drivers for more than two decades. Also, we have BSD based systems at a couple of places.
However, as a user of almost all mainstream OSes (at the same time, for different reasons), and planning to include OpenBSD to that roster (taking care of a fleet takes time), I'd love to everyone select the correct tool for their applications and don't throw stones at people who doesn't act like them.
Please remember that we all sit in houses made of glass before throwing things to others.
Oh, also please don't make assumptions about people you don't know.
You could describe Richard Stallman as someone who refuses to use proprietary software because he sees using it as becoming complicit--however indirectly--in a technology ecosystem that violates the values he’s committed to.
"Just don't use X" is in fact a very engaged and principled response. Try again.
(I like OpenBSD, but) It is extremely hard to compete with Linux on hardware support / driver coverage.
I like the GPL for the kernel, so I wouldn't switch.
What should I do if I like AGPLv3 kernels?
then you'd have a write a new kernel
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.
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.
> companies
That's the keyword.
Companies. Not people.
>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?
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.
“ensure that things are as they are expected to be” according to who, and for who's benefit? Certainly not the person sitting in front of the computer.
The system owner. Usually that is the same entity that owns the secure boot keys, which can be the person that bought a device or another person if the buyer decides to delegate that responsibility (whether knowingly or unknowingly).
In my case I am talking about myself. I prefer to actually know what is running on my systems and ensure that they are as I expect them to be and not that they may have been modified unbeknownst to me.
I don't think this is right. Usually, the entity that owns secure boot keys is a large tech corporation which paid to install their keys on all new computers.
You can enroll your own and LP goal is basically based on the assumption that you can enroll your own
Until you cannot.
This is only the case if the person sitting in front of it does not own the keys.
And from this you can safely conclude that users will be under severe pressure to surrender them.
It prevents malware that obtained root access once from forever replacing your kernel/initrd and achieving persistence that way.
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.
Then you reset the firmware and re-enroll your SB keys or disable it completely.
> re-enroll your SB keys
This is possible only temporarily.
> we try to make every new feature that might be disruptive optional in systemd and opt-in
I find it hard to believe. Like, at all. Especially given that the general posture of your project leader is the exact opposite of that.
> systemd a healthy project
I can see that we share the same view that there are indeed differences in opinion.
> will the maintainer of systemd use their position to push this on everyone
Can you imaging the creator of systemd not to?
systemd is the most well supported init systemd there.
Trusted computing and remote attestation is like two people who want to have sex requiring clean STD tests first. Either party can refuse and thus no sex will happen. A bank trusting a random rooted smartphone is like having sex with a prostitute with no condom. The anti-attestation position is essentially "I have a right to connect to your service with an unverified system, and refusing me is oppression." Translate that to the STD context and it sounds absurd - "I have a right to have sex with you without testing, and requiring tests violates my bodily autonomy."
You're free to root your phone. You're free to run whatever you want. You're just not entitled to have third parties trust that device with their systems and money. Same as you're free to decline STD testing - you just don't get to then demand unprotected sex from partners who require it.
But I'm not having sex with my bank.
You do know what analogies are, right?
A fundamentally flawed way to make an argument?
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?
"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?"
Because there are an infinite ways for a computer to be insecure and very few ways for it to be secure.
Checks were a form of attestation because they contained security features that banks would verify.
Would YOU be willing to use a bank that refused to use TLS? I didn't think so. How is you refusing to accept remote attestation and the bank refusing to connect to you any different?
So both consent to sex and now one thinks they're entitled to marriage. That's where this inevitably leads, user/customer lock-in and control.
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.
"It's going to be every god damned thing on the internet. Why? Because why the hell not"
This is not a persuasive argument.
You are also ignoring the fact that YOU can use remote attestation to verify remote computers are running what they say they are.
"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."
You actually sound like you are having a nervous breakdown. Perhaps you should take a vacation.
You are trying to portrait it as an exchange between equal parties which it isn't. I am totally entitled not to have to use a thrid-party-controlled device to access government services. Or my bank account.
remote attestation is just fancy digital signatures with hardware protected secret keys. Are you freaking out about digital signatures used anywhere else?
Trusted computing boil down to restricting what software I'm allowed to run on hardware I own and use. The technical means to do so are irrelevant.
"Trusted computing boil down to restricting what software I'm allowed to run on hardware I own and use." Remote attestation doesn't do this.
It absolutely does. Emphasis on use. The last thing I need is my bank requiring me to use a Poettering-certified distribution because anything else is "insecure".
You are acting very entitled thinking you can dictate the conditions under which you can connect to other people's computers. This is a "it takes two to tango" situation. I'm sure YOU would refuse to connect to any bank that refuses to use TLS.
No man, there is no tango. "It takes two" doesn't apply when one part is a huge corporation.
BOTH parties have to agree on the conditions under which the computers will connect and EITHER can reject them.
> You're just not entitled to have third parties trust that device with their systems and money.
But its a bank, right? Its my money.
If malware on your phone steals it the bank could be on the hook. The bank can set terms on how you access their computers.
Can it sets terms on my religious and political views? I'm not speaking about race and sex, you cannot choose them (ok, sex you could in some jurisdictions, and there is difference between sex and gender, please, don't be nitpicky here), but about things I can choose same as I can choose my hardware and software to run.
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.
You DO understand you can own more than one phone, right? Just use one that isn't rooted as a dedicated banking device and the rooted phone for whatever else you need. You are making life far too hard.
But to have two desktop computers — one attestable and other not — is much more hard than two mobile devices.
And we are discussing this movement here. You know, пive him an inch and he'll take a yard.
It is actually very easy to use VMs for the non attesting machine.
Would YOU be willing to use a bank that refused to use TLS? I didn't think so. How is you refusing to accept remote attestation and the bank refusing to connect to you any different?
Frankly this disgusts me. While there are technically user-empowering ways this can be used, by far the most prevalent use will be to lock users/customers out of true ownership of their own devices.
Device attestation fails? No streaming video or audio for you (you obvious pirate!).
Device attestation fails? No online gaming for you (you obvious cheater!).
Device attestation fails? No banking for you (you obvious fraudster!).
Device attestation fails? No internet access for you (you obvious dissident!).
Sure, there are some good uses of this, and those good uses will happen, but this sort of tech will be overwhelmingly used for bad.
Remote attestation only works because your CPU's secure enclave has a private key burned-in (fused) into it at the factory. It is then provisioned with a digital certificate for its public key by the manufacturer.
1. Are reproducible builds and transparency logging part of your concept?
2. Are you looking for pilot customers?
Damn, you are thirsty!
Are these some problems you've personally been dealing with?
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.
This appears to be the only comment worth reading. Thanks.
These kinds of problems are very common in certain industries.
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?
A full trusted boot chain allows you to use a reboot to revert back to a trusted state after suspected runtime compromise.
Can you share more details at this point about what you are trying to tackle as a first step?
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.
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?
> 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.
lol
Probably also some of the things that were described here? https://0pointer.net/blog/fitting-everything-together.html
Are you guys hiring? I can emulate a grim smile and have no problem being diabolical if the pay is decent so maybe I am a good fit? I can also pet goats
Great; how can I short it?
The photos depict these people as funny hobbits :D. Photographer trolled them big time. Now, the only question left is whether their feet are hairy.
---
Making secure boot 100 times simpler would be a deffo plus.
I'm not seeing any big problems with the portraits.
Having said that, should this company not be successful, Mr Zbyszek Jędrzejewski-Szmek has potentially a glowing career as an artists' model. Think Rembrandt sketches.
I look forward to something like ChromeOS that you can just install on any old refurbished laptop. But I think the money is in servers.
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.
Some people just can't stop making other's lives more miserable, can they.
So I imagine Lennart Poettering has left Microsoft.
Rodrigo from the Amutable team here. Yes, Lennart has left Microsoft.
Ah, thanks for jumpin in.
I chuckle because their official adress is just 20 minutes from my home / current location.
I wish you great success
- How different is this from Fedora BlueFin or silverblue?
- it looks like they want to build a ChromeOS without Google.
Is this headed towards becoming a new Linux distribution or hardening existing ones?
Are there VCs who participated in funding this or are you self funded?
Will this do remote attestation ? What hardware platforms will it support? (Intel sgx, AMD sev, AWS nitro?)
fantastic news, congrats on launching! it's a great mission statement a fanstastic ensemble for the job
So much negativity in this thread. I actually think this could be useful, because tamper-proof computer systems are useful to prevent evil maid attacks. Especially in the age of Pegasus and other spyware, we should also take physical attack vectors into account.
I can relate to people being rather hostile to the idea of boot verification, because this is a process that is really low level and also something that we as computer experts rarely interact with more deeply. The most challenging part of installing a Linux system is always installing the boot loader, potentially setting up an UEFI partition. These are things that I don't do everyday and that I don't have deep knowledge in. And if things go wrong, then it is extra hard to fix things. Secure boot makes it even harder to understand what is going on. There is a general lack of knowledge of what is happening behind the scenes and it is really hard to learn about it. I feel that the people behind this project should really keep XKCD 2501 in mind when talking to their fellow computer experts.
> I actually think this could be useful
Yeah it could be. Could. But it also could be used for limiting freedoms with general purpose computing. Guess what is it going to be?
> hostile to the idea of boot verification, because this is a process that is really low level
Not because of that.
Because it's only me who gets to decide what runs on my computer, not someone else. I don't need LP's permission to run binaries.
I personally do not worry about an evil maid attack _at all_. But I do worry about someone restricting what I can do with _my_ computer.
I mean, in theory, the idea is great. But it WILL be misused by greedy fucks.
How do they plan to make Linux (with MLoCs...) deterministic?
Why not adopt seL4 like everybody else who is not outright delusional[0][1]?
0. https://sel4.systems/Foundation/Membership/
1. https://sel4.systems/use.html
Will you always offer an option to end users to disable the system if they so desire?
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.
They will. Just like they pretend it's the distros who made systemd ubiquitous.
So it's going to be someone disabling this for end users.
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.
How long until you have SIL-4 under control and can demonstrate it?
Great team, hope you guys all the best!
Just get a Mac, I guess.
Hmph, AFAIK systemd has been struggling with TPM stuff for a while (much longer than I anticipated). It’s kinda understandable that the founder of systemd is joining this attestation business, because attestation ultimately requires far more than a stable OS platform plus an attestation module.
A reliably attestable system has to nail the entire boot chain: BIOS/firmware, bootloader, kernel/initramfs pairs, the `init` process, and the system configuration. Flip a single bit anywhere along the process, and your equipment is now a brick.
Getting all of this right requires deep system knowledge, plus a lot of hair-pulling adjustment, assuming if you still have hair left.
I think this part of Linux has been underrated. TPM is a powerful platform that is universally available, and Linux is the perfect OS to fully utilize it. The need for trust in digital realm will only increase. Who knows, it may even integrate with cryptocurrency or even social platforms. I really wish them a good luck.
It might be a good time to rewrite systemd in rust...
Amazing, I wish them great success! <3
amutable -k
Terrible idea, I hope go bankrupt.
I can see like a 100 ways this can make computing worse for 99% people and like 1-2 scenarios where it might actually be useful.
Like if the politicians pushing for chat control/on device scanning of data come knocking again and actually go through (they can try infinitely) tech like this will really be "useful". Oops your device cannot produce a valid attestation, no internet for you.
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.
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.
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.
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
> 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.
> 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.
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.
> it will be used for movies, government services, banks
I really, really don't think these entities care enough about desktop Linux. I'd be way more worried about some kind of Windows web-based attestation appearing. If that happens I really do think there's a bit of an alarm to sound, because this will make using desktop Linux inconvenient in the way attestation has made using alternate Android ROMs inconvenient.
> Because you are obviously a hacker, why else would anyone want to compile and run programs.
People buy computers to run programs, it doesn't behoove anyone to prevent this. These things are driven by economics, not some weird arbitrary drive towards evil. Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
> 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.
Why does everyone land on this complete non sequitur? It's not the flip of a switch, that's not how UEFI Secure Boot works to start with and even then, UEFI Secure Boot is not the root of trust on x86.
This was indeed the big "Free Software" vs UEFI "Secure" Boot conspiracy theory 20+ years ago, but it didn't make sense then, doesn't make sense now, and sure enough, hasn't come to pass. First off, Microsoft aren't Intel, who own the root of trust on Intel CPUs. Second off, again, there's no incentive to do this. CPUs are a competitive market and people buy CPUs to run code. There is no reason for Intel to suddenly decide to exclusively enforce firmware verification in a way that only chained down to one vendor's keys; they're in the business of selling CPUs to people who want to run things. Also, the notion that some CPU vendor will suddenly lock down firmware keys has nothing to do with the article in question or the notion of an immutable or attestable Linux.
Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
Where I live in Europe, Fairphones are becoming fairly popular (as in, I encounter non-tech people using Fairphones). A subset of those users run /e/OS (anti-Google/big tech sentiment is growing pretty strong). This is increasingly becoming a risk for Google, because if /e/OS takes off big time in Europe, it would be easy to support a European app store besides Google Play and F-Droid (which the /e/OS App Lounge already support), leading to a loss of 30% on app spending.
Google will abuse their remote attestation implementation to shut out competitors. If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
> If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
Google actually "gave" customers the choice here, although I agree with you that it's crappy and there was almost surely some monopolistic intent -
There _is_ a standard implementation, the Hardware Attestation API. Unfortunately it is annoying to use in a practical way; it requires a fair amount of PKI-wrangling (although there's a Google library for it) and more importantly to allow non-Google trust chains but still enforce boot security, app developers need all of the verifiedBootKey hashes for the non-Google trust chains they want to trust. This makes sense, but unfortunately becomes a maintenance problem and turns app developers off of this.
So, app developers choose the Play Integrity API instead because it's easy, even though they get the side effect that they verify that the device is a licensed Google Play device rather than just a "clean" Android device.
All this is to say that if something like /e/OS were to actually take off, app developers could upgrade their apps to support attestation with the Hardware Attestation API with some extra effort - Google aren't really preventing them and the feature is there.
Anyway, going all the way back to the original story again, I still can't buy into the hand-wringing. A verified, attestable Linux on the server (or for stuff like forward deployed devices) seems quite cool and useful to me, and while I respect the issues with client attestation and the negative effect it can have on hardware ownership, I both don't see it as a practical outcome from this company and don't see it as a practical threat on the desktop at this time.
No worries here as EU is slowly pushing to ban OS-unlocked phones under the guise of "think of the children^Wradio spectrum".
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.
> 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.
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.
I don't see how this relates in any way to Amutable and it has been a "concern" for 20+ years (which has never come to pass). How do you think this relates at all?
Before this point in time, Linux never supported being an immutable image. Neither filesystems, nor the mechanism to lock it down was there. The best you could do was, TiVoization, but that would be too obvious and won't fly.
Now we have immutable distributions (SuSE, Fedora, NixOS). We have the infrastructure for attestation (systemd's UKI, image based boot, and other immutability features), TPMs and controversially uutils (Which is MIT licensed and has the stated goal to replace all GNU userspace).
You can build an immutable and adversarial userspace where you don't have to share the source, and require every boot and application call to attest. The theoretical thickness of the wall is both much greater and this theoretical state is much easier to achieve.
20 years ago the only barrier was booting. After that everything was free. Now it's possible to boot into a prison where your every ls and cd command can be attested.
Oh, Rust is memory safe. Good luck finding holes.
> Before this point in time, Linux never supported being an immutable image.
What? As just one example, dm-verity was merged into the mainline kernel 13 years ago. I built immutable, verified Linux systems at least ten years ago, and it was considered old hat by the time I got there.
> The best you could do was, TiVoization, but that would be too obvious and won't fly.
What does this even mean? "TiVoization" is the slang for "you get a device that runs Linux, you get the GPL sources, but you can't flash your own image on the device because you don't own the keys." This is the exact same problem then as it was now and just as "obvious?"
I understand the fears that come from client attestation (certainly, the way it has been used on Android has been majorly detrimental to non-Google ROMs), but, to the Android point, the groundwork has always been there.
I'd be very annoyed if someone showed up and said "we're making a Linux-based browser attestation system that your bank is going to partner on," but nobody has even gone this direction on Windows yet.
> Oh, Rust is memory safe. Good luck finding holes.
I break secure boot systems for a living and I'd say _maybe_ half of the bugs I find relate to memory safety in a way Rust would fix. A lot of systems already use tools which provide very similar safety guarantees to Rust for single threaded code. Systems are definitely getting more secure and I do worry about impenetrable fortresses appearing in the near future, but making this argument kind of undermines credibility in this space IMO.
Have you run an Android device recently?
Yes, I reference Android client attestation in my comments in this thread frequently. I actually see this company as likely to be the flip side of the “bad” client attestation coin; server attestation actually provides a lot of nice properties to end users and providers who wish to provide secure solutions with very limited user downside.
It won't remain "server" attestation. It will become "client" attestation, with the end result that you won't own your own machine anymore, you'll just be paying for a client device upon which you won't control the hardware or software anymore. See any mobile phone at all, anymore.
I don’t see anyone investing in this for general purpose desktop Linux in the state desktop Linux exists today; the harbinger of the Desktop Linux Apocalypse would be web-based Windows attestation (just as Android attestation is eroding alt-OSes) which feels like a viable “threat” but thankfully doesn’t seem to be happening just yet.
I do think this approach might get used for client attestation in gaming, which I actually don’t mind; renting/non-owning a client that lets me play against non cheaters is a pretty good gaming outcome, and needing a secure configuration to run games seems like a fine trade for me (vs for example needing a secure desktop configuration to access my bank, which would be irksome).
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
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
The idea is that by protecting boot path you build a platform from which you can attest the content of the application. The goal here is usually that a cloud provider can say “this cryptographic material confirms that we are running the application you sent us and nothing else” or “the cloud application you logged in to matched the one that was audited 1:1 on disk.”
I knew they had an authoritarian streak. This is not surprising, and frankly horrifyingly dystopian.
"Those who give up freedom for security deserve neither."
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!
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.
How do you take the generally negative feedback from the community here?
I have no more information about your product that you have shared but I'm already scared and extremely pessimistic given the team and the ambition.
"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?
"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
This sounds like a net negative for the end user
Not if the end user is an operator of safety critical equipment, such as rail or pro audio or any of a number of industries where stability and reproducibility is essential to the product.
Ever seen a default ubuntu splash screen/wallpaper on a train, coffee machine, airport terminal kiosk, bus, or other big piece of slow moving, appliance-y thing?
That is why Ubuntu Core (and similar) exist. More secure, better update strategy, lower net cost. I don't agree with the licensing or pricing model, but there are perfectly good technical reasons to use it.
That's because it is a net negative to the end user and to society at large.
If the end users do not want the net negative, maybe they should pay for the security features instead of expecting everything for free.
I don't understand. The user will not have a choice.
Appreciate the clarification, but this actually raises more questions than it answers.
A "robust path to revenue" plus a Linux-based OS and a strong emphasis on EU / German positioning immediately triggers some concern. We've seen this pattern before: wrap a commercially motivated control layer in the language of sovereignty, security, or European tech independence, and hope that policymakers, enterprises, and users don't look too closely at the tradeoffs.
Europe absolutely needs stronger participation in foundational tech, but that shouldn't mean recreating the same centralized trust and control models that already failed elsewhere, just with an EU flag on top. 'European sovereignty' is not inherently better if it still results in third-party gatekeepers deciding what hardware, kernels, or systems are "trusted."
Given Europe's history with regulation-heavy, vendor-driven solutions, it's fair to ask:
Who ultimately controls the trust roots?
Who decides policy when commercial or political pressure appears?
What happens when user interests diverge from business or state interests?
Linux succeeded precisely because it avoided these dynamics. Attestation mechanisms that are tightly coupled to revenue models and geopolitical branding risk undermining that success, regardless of whether the company is based in Silicon Valley or Berlin.
Hopefully this is genuinely about user-verifiable security and not another marketing-driven attempt to position control as sovereignty. Healthy skepticism seems warranted until the governance and trust model are made very explicit.
We detached this subthread from https://news.ycombinator.com/item?id=46784719.
[dead]
[flagged]
[flagged]
You're right, they shouldn't have started a company, that would be better for diversity.
[flagged]
No personal attacks on HN, please.
https://news.ycombinator.com/newsguidelines.html
Please delete my account. Thanks
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?
This is not about the person being attacked, it's about what this kind of thing does to us as a community. It's not what the site is for, and destroys what it is for.
My comment was not a personal attack. But I can rephrase it if you want it more in the spirit of the guidelines. Here we go:
If you don't think that's a community opinion, it's at least an AI's opinion, since all I prompted it with was "rewrite my comment to follow the HN guidelines"[flagged]
[flagged]
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.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
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.
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.
[flagged]
Disgusting.
People demonize attestation. They should keep in mind that far from enslaving users, attestation actually enables some interesting, user-beneficial software shapes that wouldn't be possible otherwise. Hear me out.
Imagine you're using a program hosted on some cloud service S. You send packets over the network; gears churn; you get some results back. What are the problems with such a service? You have no idea what S is doing with your data. You incur latency, transmission time, and complexity costs using S remotely. You pay, one way or another, for the infrastructure running S. You can't use S offline.
Now imagine instead of S running on somebody else's computer over a network, you run S on your computer instead. Now, you can interact with S with zero latency, don't have to pay for S's infrastructure, and you can supervise S's interaction with the outside world.
But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.
However --- if S's author could run S on your computer in such a way that he could prove you haven't tampered with S or haven't observed its secrets, he can let you run S on your computer without giving up control over S. Attestation, secure enclaves, and other technologies create ways to distribute software that otherwise wouldn't exist. How many things are in the cloud solely to enforce access control? What if they didn't have to be?
Sure, in this deployment model, just like in the cloud world, you wouldn't be able to run a custom S: but so what? You don't get to run your custom S either way, and this way, relative to cloud deployment, you get better performance and even a little bit more control.
Also, the same thing works in reverse. You get to run your code remotely in a such a way that you can trust its remote execution just as much as you can trust that code executing on your own machine. There are tons of applications for this capability that we're not even imagining because, since the dawn of time, we've equated locality with trust and can now, in principle, decouple the two.
Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.
> People demonize attestation. They should keep in mind that far from enslaving users, attestation actually enables some interesting, user-beneficial software shapes that wouldn't be possible otherwise. Hear me out.
But it won't be used like that. It will be used to take user freedoms out.
> But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.
That use case you're describing is already there and is currently being done with DRM, either in browser or in app itself.
You are right in the "it will make easier for app user to do it", and in theory it is still better option in video games than kernel anti-cheat. But it is still limiting user freedoms.
> Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.
Majority of the uses will be user-hostile things. Because those are only cases where someone will decide to fund it.
> Attestation, secure enclaves, and other technologies create ways to distribute software that otherwise wouldn't exist. How many things are in the cloud solely to enforce access control? What if they didn't have to be?
To be honest, mainly companies need that. personal users do not need that. And additionally companies are NOT restrained by governments not to exploit customers as much as possible.
So... i also see it as enslaving users. And tell me, for many private persons, where does this actually give them for PRIVATE persons, NOT companies a net benefit?
additionally:
> This potential shouldn't prevent our inventing new kinds of tool.
Why do i see someone who wants to build an atomic bomb for shit and giggles using this argument, too? As hyperbole as my argument is, the argument given is not good here, as well.
The immutable linux people build tools, without building good tools which actually make it easier for private people at home to adapt a immutable linux to THEIR liking.
The atomic bomb is good example of what I'm talking about. The reason we haven't had a world war in 80 years is the atomic bomb. Far from being an instrument of misery, it's given us an age of unprecedented peace and prosperity. Plus, all the anti-nuclear activism in the world hasn't come one step closer to banishing nuclear weapons from the earth.
In my personal philosophy, it is never bad to develop a new technology.
I will put some trust into these people if they make this a pure nonprofit organization at the minimum. Building ON measures to ensure that this will not be pushed for the most obvious cases, which is to fight user freedom. This shouldn't be some afterthought.
"Trust us" is never a good idea with profit seeking founders. Especially ones who come from a culture that generally hates the hacker spirit and general computing.
You basically wrote a whole narrative of things that could be. But the team is not even willing to make promises as big as yours. Their answers were essentially just "trust us we're cool guys" and "don't worry, money will work out" wrapped in average PR speak.
> trust us we're cool guys
I'm guessing you're referencing my comment, that isn't what I said.
> But the team is not even willing to make promises as big as yours.
Be honest, look at the comment threads for this announcement. Do you honestly think a promise alone would be sufficient to satisfy all of the clamouring voices?
No, people would (rightfully!) ask for more and more proof -- the best proof is going to be to continue building what we are building and then you can judge it on its merits. There are lots of justifiable concerns people have in this area but most either don't really apply what we are building or are much larger social problems that we really are not in a position to affect.
I would also prefer to be to judged based my actions not on wild speculation about what I might theoretically do in the future.
> bad actors can use attestation technology to do all sorts of user-hostile things
Not just can. They will use it.
Shall it be backdoorable like systemd-enabled distro nearly had a backdoorable SSH? For non-systemd distro weren't affected.
Why should we trust microsofties to produce something secure and non-backdoored?
And, lastly, why should Linux's security be tied to a private company? Oooh, but it's of course not about security: it's about things like DRM.
I hope Linus doesn't get blinded here: systemd managed to get PID 1 on many distros but they thankfully didn't manage, yet, to control the kernel. I hope this project ain't the final straw to finally meddle into the kernel.
Currently I'm doing:
But Promox is Debian based and Debian really drank too much of the systemd koolaid.So my plan is:
And then I'll be, at long last, systemd-free again.This project is an attack on general-purpose computing.
First thing that comes to mind is anti cheat software. Would that be something solved if these objectives are achieved?
Cheating was solved before any of this rootkit level malware horseshit.
Community ran servers with community administration who actually cared about showing up and removing bad actors and cheaters.
Plenty of communities are still demonstrating this exact fact today.
Companies could 100% recreate this solution with fully hosted servers, with an actually staffed moderation department, but that slightly reduces profit margins so fuck you. Keep in mind community servers ran on donations most of the time. That's the level of profit they would lose.
Companies completely removed community servers as an option instead, because allowing you to run your own servers means you could possibly play the game with skins you haven't paid for!!! Oh no!!! Getting enjoyment without paying for it!!!
All software attempts at anti-cheat are impossible. Even fully attested consoles have had cheats and other ways of getting an advantage that you shouldn't have.
Cheating isn't defined by software. Cheating is a social problem that can only be solved socially. The status quo 20 years ago was better.
Everyday the world is becoming more polarized. Technology corporations gain ever more control over people's lives, telling people what they can do on their computers and phones, what they can talk about on social platforms, censoring what they please, wielding the threat of being cutoff from their data, their social circles on a whim. All over the world, in dictatorships and also in democratic countries, governments turn more fascist and more violent. They demonstrate that they can use technology to oppress their population, to hunt dissent and to efficiently spread propaganda.
In that world, authoring technology that enables this even more is either completely mad or evil. To me Linux is not a technological object, it is also a political statement. It is about choice, personal freedom, acceptance of risk. If you build software that actively intends to take this away from me to put it into the hands of economic interests and political actors then you deserve all the hate you can get.
> To me Linux is not a technological object, it is also a political statement. It is about choice, personal freedom ...
I use Linux since the Slackware day. Poettering is the worse thing that happened to the Linux ecosystem and, of course, he went on to work for Microsoft. Just to add a huge insult to the already painful injury.
This is not about security for the users. It's about control.
At least many in this thread are criticizing the project.
And, once again of course, it's from a private company.
Full of ex-Microsofties.
I don't know why anyone interested in hacking would cheer for this. But then maybe HN should be renamed "CN" (Corporate News) or "MN" (Microsoft News).
> Poettering is the worse thing that happened to the Linux ecosystem and, of course, he went on to work for Microsoft. Just to add a huge insult to the already painful injury.
agreed, and now he's planning on controlling what remains of your machine cryptographically!
> I use Linux since the Slackware day. Poettering is the worse thing that happened to the Linux ecosystem
Same here, Linux since about 1995. Same opinion.
> And, once again of course, it's from a private company. Full of ex-Microsofties.
And funded. And confident they will sell the product well.
Lennart Poettering. The leading expert in forcing things down your throat. Great.
Been wanting this ever since doing it in Fuchsia. Really excited to see added focus and investment in this for the Linux ecosystem.
For all those people saying negative please see all the comments when RedHat was acquired by IBM (2018)
https://news.ycombinator.com/item?id=18321884
- Linux is better now
- Nothing bad
Surely Redhat has gone from being the defacto default Linux to relative obscurity?