Slashdot Mirror
Systemd Getting UEFI Boot Loader
New submitter mrons writes: Many new features are coming for systemd. This includes the ability to do a full secure boot. As Lennart Poettering mentions in a Google+ comment: "This is really just about providing the tools to implement the full trust chain from the firmware to the host OS, if SecureBoot is available. ... Of course, if you don't have EFI SecureBoot, than nothing changes. Also if you turn it off, than nothing changes either. [sic]" Phoronix notes, "Gummiboot is a simple UEFI boot manager that's been around for a few years but only receives new work from time-to-time. Lennart and Kay Sievers are looking at adding Gummiboot to systemd to complete the safety chain of the boot process with UEFI Secure Boot. Systemd will communicate with this UEFI boot loader to ensure the system didn't boot into a compromised state."
FreeBSD user here since over a decade. Welcome.
You haven't seen FreeBSD crash? It only means that you haven't seen enough, yet. FreeBSD is a great system and I recommend it to everyone who can manage it, but you don't need to mention stability as a feature, because it is not the highlight about FreeBSD. You don't install a system and watch how stable it is, but how useful it is (for you and your special requirements).
The best thing about FreeBSD are the FreeBSD Ports and how much commitment there is to make every possible application work on the system. You have basically far more possibilities and options than on Linux distributions thanks to the great job they are doing on this system.
A second point is that it is easier to feel comfortable on the system, because the whole thing is consistent and easy to understand, provided you take some time and learn about the concepts.
I assume you know that testing is a development branch and is supposed to break,
No, it's not "supposed to break". Heck I ran unstable for years and only had 1 serious problem in all that time. If you really want crazy go to experimental.
Testing is for hashing out deep and difficult bugs not "This is a complete POS"
That's the problem. There isn't a stable release with systemd.
Fedora has so far released six stable releases with systemd, and Red Hat shipped their first stable release with systemd last summer.
The code isn't audited, nor has it seen actual production testing. It was just foisted on the end users without any transition period, possibly breaking every single app that uses the init.d mechanism for starting and control.
It has been shipping in Fedora for the past four years, and in RHEL since last summer. If that's not production testing then what is?
To boot, with systemd's ability to listen on the network, it has a good chance of becoming a massive remote root exploit in the waiting. Does it have any internal security? We can cross fingers that this large blob of new code does more harm than good, but all it takes is one glitch, and it would mean havoc worse than the RTM worm on the UNIX side ages ago, or the Windows worms in the early 2000s.
Inetd has been doing that for years. It has since moved to a different project. Big deal?
Not enough coffee this morning, I quoted Unstable. Testing has similar warnings and you will find that every time there is major plumbing changes testing breaks. It's inevitable as edge cases break things.
Search the archives, there have been plenty of instances where a package pushed into testing broke people's machines. I remember several.
https://en.wikipedia.org/wiki/...
SystemD is fucked up by design. Do one thing. Do it right.
Now they're taking a separate, barely updated UEFI bootloader and shoehorning it in as well. They would have been a bit better of at least starting from Grub2.
If the user can change the keys then I don't see a problem with it, and there are plenty of UEFI motherboards where you can change the keys.
Just look at this presentation, where a presenter dares to suggest that some people don't want Gnome, and then Lennart construes this (immediately) as an attack on handicapped people or people who don't speak English. I'm not exaggerating at all - as soon as someone even suggests doing things a different way, he'll just jump up and say, 'you must hate handicapped people.'
In fact, this is exactly how Debian has turned now that it's been taken over by his cronies. Anyone who even dares to go against him and Gnome gets insta-banned.
It's just a simple and very extreme case of playing the victim: pretending he's done nothing wrong and claiming all kinds of discrimination and personal attacks when people criticize him, even if they're just saying that they don't want to use systemd or whatever clusterfuckery he's come up with most recently.
I've said it before and I'll say it again - Poettering and Co. are the new Steve Jobs Klan of open source, and we need immediate action to get rid of his influence. Everything he's doing for the Free Software community is bad and he should be excommunicated permanently.
It WAS that way:
A Linux-based system is a modular Unix-like operating system. It derives much of its basic design from principles established in Unix during the 1970s and 1980s. Such a system uses a monolithic kernel, the Linux kernel, which handles process control, networking, and peripheral and file system access. Device drivers are either integrated directly with the kernel or added as modules loaded while the system is running.
Other people in this thread have already point out that the direction systemd is headed will leave us with 2 binaries: The kernel and systemd. What next, systemd incorporates a mysql server?
More like different focuses.
FreeBSD is nice, but it's very server-oriented. Sure you can use it on a desktop through ports, but everything's still basically assuming you're on a server.
SystemD is like PulseAudio, CUPS, and NetworkManager - they're tools to handle the complex desktop use cases that don't exist with servers.
Of course, one thing FreeBSD does have is a general guidance and an avoidance of the latest shiny or political plays, which means a lot of Linux cruftiness is avoided, so stability in that form means things don't change too much.
But, desktop users have a lot of requirements that just cannot be band-aided over like they do in Linux where you have spitwads, gum and duct tape holding together a lot of the system. Sure it works, but it's an extremely fragile system that's just begging for breakage.
Here's some use cases that are extremely common in a desktop, but not at all on a server, and how various packages handle them.
Audio - modern desktops have multiple audio paths - from HDMI to plain old speaker/headphone/line outs. And new ones appear and disappear constantly (say, Bluetooth). And audio needs to be mixed because the user might be watching a YouTube video when the system needs to alert them via a system sound. Or say, the user is listening to music, and then a VoIP call comes in which means muting the audio from the music player and activating the communications audio path (which can be completely different audio paths - the music may play through a speaker path, while the VoIP takes place over a headset using either a separate set of ADCs and DACs, Bluetooth, or whatever). Or perhaps the user is listening to music over their A/V system using HDMI audio. Then they turn off their A/V system losing the audio connection - audio now needs to be transported to a secondary source transparently to the application (can't have apps crashing because the audio device disappeared). Or how about a user opening an audio device for exclusive use (low latency, bit-perfect, whatever), and the system needs to play a sound (VoIP, alert, whatever). If there's no other audio path, it's a too-bad situation. But if there's another set of speakers or audio, why not route that audio that way so the user can get the alert through a secondary audio path?
Networks are just as tricky - you want to connect to many different networks with differing roles - perhaps if you're at home, you bring down the firewall, while if you're on the go, the firewall goes up and maybe the VPN does too. Suddenly media connections are very important too because once you disconnect, you don't know if the next attachment will be to a trusted or untrusted network. And the firewall may need to manage different rules - like perhaps the HTTP server is allowed on all networks - public, private, VPN, whatever, while say Samba should only be accessible on private networks only. Repeat for other applications as necessary.
SystemD is similar - a lot of services these days aren't launched on the system's behalf, but on the user. Right now there are dozens of different ways to have services launch when you log in - every environment provides a different way of doing it and there's no standard, so perhaps if you need a service to launch on Ubuntu when you log in, it won't work on Fedora. That's a huge mess - why not have something that's good at managing processes do it? Sure you have system services that start up on system boot, but there are a lot
In Windows, it's not unheard of that a piece of malware with sufficient access interjects itself where the next boot will be picked up before the OS has a chance to set up it's own protection. Of course my complaint is that this vector would have easily been sidestepped without a huge firmware mess. If the OS set up access to that area as very very very very special, requiring signed code within the OS to modify that section of the platform, then the problem would have been solved. .
Sorry, but no. If you knew anything about threat modelling and OS design, you would know that code running at a trust level cannot protect against other code running with the same trust. The x86 architecture does have 4 levels, but for a number of reasons (mostly portability) practically no OSes use more than 2 levels (rings): protected/kernel and user mode.
What you are proposing is using a 3rd ring - something more privileged than kernel mode. This would constitute a major architectural redesign and would trash portability/compatibility with other architectures.
The fact is that UEFI Secure Boot is a very effective mechanism for blocking boot sector infections. As Windows has grown ever more resilient against permanent infections (app/driver signing, checksum tables, strong named assembly cache etc) malware authors were forced into infecting at an earlier stage of the boot process, if they wanted to take up permanent residence.
The OS kernel mode MUST have the capability to write all sectors of the disk. It can effectively block usermode apps from writing such sectors, but if kernel mode driver contains a vuln, rogue code can bypass any security mechanisms enforced by the kernel. It can just jump to the address efter the security check or control the IO itself.
Bootkits exists for Wndows. It was a real threat. A few unscrupolous individuals (lookng at you Garett) chose to instigate a FUD campaign, deliberately misrepresenting facts and knowlingly failing to correct misunderstandings when they advanced their case.
And you are still part of that.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
What stopped me? Many things. Here's a few.
The systemd debate reduced the Debian lists to an endless flamewar over three years long. debian-devel is just toxic; it's not useful for any constructive development discussion. I unsubscribed from almost all the lists a year back. I can't describe how wearing and demotivating this is. Reading the archives since then, it hasn't improved.
Most of the software I write for Debian is core systems programming stuff. Straight out of APUE (Stevens). Over the last year, I've had a stream of bug reports about things not working correctly under systemd. Some fairly fundamental POSIX syscalls and tools no longer have the same behaviour when running under systemd. By "design". That's a fairly huge compatibility break with every other UNIX-like system out there, and one which hasn't seen much attention. But I'm somehow expected to rework my code to work around the breakage systemd brought with it. Breakage which has nothing to do with me. Code which isn't even remotely anything to do with an init system and which is portable code running on many other systems. That's crossed a line. systemd can't and won't be supported.
I can work on sysvinit, openrc to a lesser extent. For several years it's been all take and no give with the systemd people. We can't do work on integrating openrc since this would require support for runscripts in systemd. What's the chance of that? Zero. Any changes, even minor ones, require superhuman effort to achieve. Essentially, it's an uphill battle to do anything and Debian is no longer a pleasant or productive environment to work in, primarily thanks to the horrible "our way or the highway" attitude of the systemd people. Since when was free software about dictating how everyone must do things? Silly me, I used to think it was about having the personal freedom to tinker with things as I liked to meet my needs. I'm a volunteer, and I give up vast amounts of my life to contribute to free software and Debian. This was previously a fun, collaborative, productive endevour for which my efforts benefitted many people. It's now deeply unpleasant and I don't like being abused, ridiculed and trodden on by the systemd people and their enablers. I'll move on to new and better things. I spent the last decade as the primary maintainer of the core Debian build tools, and later of sysvinit. I've been invested in and contributed heavily to Debian for the last 15 years. Not something easily let go.
We'll see how Devuan pans out. Until it does, I'll be carrying on the migration to FreeBSD.
Altruism only goes so far.