Comment by __MatrixMan__
3 months ago
This is pretty cool. I especially like the better encrypted boot support and that it seems to harmonize better with nixpkgs (https://discourse.nixos.org/t/sixos-a-nix-os-without-systemd...). Curious about the infusions bit.
It not having systemd seems like a bit of a distraction from all of the other stuff that has gone into it.
> I especially like the better encrypted boot support [...]
For some reason I can't directly reply to transpute's comment, but it's relevant to this thread so here goes:
> Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground [...].
Desolder the EEPROM and read the secrets - the loophole is open wide without a TPM/SEP.
The point of TPM is supposed to be that it makes "yoink the laptop" attacks unviable even for state-level actors, while desoldering and reading the flash is trivial for a hobbyist with cheap tools and some patience.
However this is still an enormous step forward. All of the recent attacks on secure boot chains on Windows[1] and Linux[2] are due to usage of partially-unencrypted core system components in a complex boot chain. Sixos takes the correct approach - minimise the attack surface. All it takes is to stop rejecting the "voodoo" and take what the hardware already offers.
[1]: https://news.ycombinator.com/item?id=42733640
> The point of TPM is supposed to be that it makes "yoink the laptop" attacks unviable even for state-level actors
On the contrary. TPM _is_ an attack in itself. Its result is that control lies not with you as the user but with whoever provided you with the TPM - relative to all software which uses the TPM. And if you can't avoid that kind of software, then the HW providers and the software providers have conspired against you to control your own hardware.
I'm specifically referring to TPM and/or SEP as a key escrow. No other commonly available hardware provides equivalent functionality. No point in going off topic on a philosophical/sociopolitical angle.
You're right. The slides about infusions and the discussion at the end about them were unexpectedly the most interesting part of the talk.
amjoseph focused a lot on the s6-init stuff, but I really think that infusions and the way they lead to more composable system configuration is the key thing here.
NixOS' module system works, but I don't think there's anybody who thinks it's particularly pretty or generalisable. As soon as you want to run one service twice with slightly varying config you're SOL ...
https://github.com/NixOS/nixpkgs/pull/372170 is a promising step towards running multiple instances of a service with separate configurations and decoupling from systemd.
systemd already has encrypted boot support. I suppose when you rip something out you have to reinvent all its functions. At that point, any rational person would question the reasons for doing so.
Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
So removing a transmission and installing/testing/improving a new design or way to solve the problem that hasn't been popularized isn't a worthy cause? How do you think we developed the first transmission? Or the various improvements we all take for granted these days? Yes, systemd can do this, but that isn't a reason to imply developing an alternative that can do the same, albeit in a different way, is irrational.
> systemd already has encrypted boot support.
It has all of those words next to a bullet point, but the implementation is quite different, and I (like the presenter and probably many many others who are clearly not you) have more confidence in a simple fuse than with systemd[1].
[1]: https://app.opencve.io/cve/?vendor=systemd_project&product=s...
> At that point, any rational person would question the reasons for doing so.
That is excellent advice. The presenter has done something you clearly cannot. You should be rational, follow your own advice, and try to figure out what those reasons are (hint: some of them are actually in the video). That might take a few hours to a few weeks of reading depending on your own experiences, and that's just how life is sometimes.
> Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
When I have a new gadget I want to produce, I'm responsible for all of the code in it, so productivity, reliability, performance, and size are important to me whether I have written the code or I have merely used it in my product. I do not understand the way these things are important to the systemd people (or even if they are important at all), so for me, systemd is off-the-table to begin with.
Or to put it another way: I never needed a car in the first place, because I'm making boats, and I'm not starting with a car just because I like the people who made the engine. Ignoring "solved problems" can just make everything more expensive, and maybe I only know that because I've seen enough people make that mistake, but sometimes this is true.
Keeping an open mind means allowing yourself to be convinced too.
Hear hear!, It's like flogging packages and frameworks at a problem without ever considering if it was easier/more efficient to roll your own.
1 reply →
NixOS checks/enforces its own reproducibility via systemd in various ways. It seems unlikely to me that replacing something battle-tested with a bunch of self-rolled brittle scripts will make it more reliable.
4 replies →
Or ripping the combustion engine out to make a better car with electric and then realizing you ALSO don't need the transmission!
And then later finding out that a transmission in an electric car will help you both with top speed and mileage, so you have to put it back.
This is just the same old "systemd sucks, let's rip it out" and then later reinvent everything it provides, because it was needed. Also commonly known as reinventing the wheel, the curse of any IT project.
1 reply →
See this is how we end up with things like electron.