systemd PID 1 can be crashed and panic the kernel: CVE-2019-6454
seclists.org/oss-sec/2019/q1/140Posted Feb 18, 2019, 6:04 PM UTC
145352
seclists.org
If PID 1 was dumb (i.e. a simple reaper, and respawns what it was told to fork off at boot when it dies), and systemd was a subreaper running below it for system mode (practically same effect as today), this would have never happened. Nevertheless, parsing untrusted input, implementing so much functionality and multiple state machines for every unit, doing it all in privileged context (and that too in PID 1, where anything going wrong will be problematic for the system) is a problem of its own, but the aforementioned setup would have prevented a kernel panic.
Yeah, all those people saying that ALL THESE YEARS never saw this coming.
Example: Author of the musl C library, in https://ewontfix.com/14/ "So how should init be done right". Nothing prevents you from running anything under init, but init itself is critical.
48
Can we please stop this circlejerk?
Just look at how many CVEs there were in the kernel or even the BSDs. Some guy found over 60 security bugs in NetBSD alone, 30 in FreeBSD and 25 in OpenBSD. All three of these are supposed to be real Unices.
In X.Org some guy once found over 120 security issues - in one audit.
It’s software, of course it has bugs.
42
I don't think you're understanding his point. These kinds of crashes are unacceptable for servers and other critical environments. All he's saying is that init should have been a simple system, which would then start systemd under it, instead of stuffing the whole thing into PID1, which is a completely valid argument.
71
I think what you don't understand is that systemd is software and when it has bugs it crashes. So does the kernel. So does all other init systems. So does everything else. It's software. It has bugs.
Whether or not a kernel panic happens or some other terrible thing happens to render your OS unable to respond to requests it doesn't matter. One is as bad as another. Sure a different design could avoid this particular problem, but that doesn't mean another approach will yield superior results.
If your 'critical environment' can be taken out by a single server crash it is some combination of:
- Actually not that critical.
- You are incompetent.
And if all these anti-systemd people are so fucking smart and know how init systems should work... ALL THEY NEED TO DO IS MAKE SOMETHING BETTER.
That's it. Make something better and people will use it. People use Systemd not because it's perfect or the best design that could possibliy exist. They don't use it because Pottering forced them. They don't use it because of some evil conspiracy involving Redhat.
They use it because it's better then sysv init, it's better then upstart, and it's better then some meat hook abortion involving init system involving shell scripts and <insert favorite random supervisor process here>.
It's the best that is available right now.
Make something better and people will use it. Systemd and Debian and Fedora all proved that init systems are not something sacred. They can and are replaced. It happened in Solaris, it happened in Mac OS X, and it happened in Linux and pretty much any other Unix OS.
-14
I think what you don't understand is that systemd is software and when it has bugs it crashes.
And what YOU don't understand is by being a little careful, it can function as it does today, and when it crashes (i.e. not event catching SIGABRT and freezing, but crashing), what happens is it dies and everything reparents to the small PID 1, which will restart it now. The damage has been MINIMIZED. Is this hard to understand?
People use Systemd not because it's perfect or the best design that could possibliy exist. They don't use it because Pottering forced them. They don't use it because of some evil conspiracy involving Redhat.
People will use what you give them to use. People were using sysvinit, people use systemd, people will something else tomorrow? What is your point? Most people don't even care.
Whether or not a kernel panic happens or some other terrible thing happens to render your OS unable to respond to requests it doesn't matter. One is as bad as another. Sure a different design could avoid this particular problem, but that doesn't mean another approach will yield superior results.
Prove how, how will it not. What is the disadvantage you see here?
I can also say that putting on a shoe won't make sure I don't step on poo and make myself dirty, ofcourse I can remove my shoe and put my bare feet on the turd? You reasoning is absurd.
It behaves as it does today, but it crashing won't make the system panic.
If your 'critical environment' can be taken out by a single server crash it is some combination of:
Actually not that critical. You are incompetent.
Yes, we were all waiting for you to tell us how incompetent we are. You're ofcourse the only one who has any competence. You've demonstrated that above already.
And if all these anti-systemd people are so fucking smart and know how init systems should work... ALL THEY NEED TO DO IS MAKE SOMETHING BETTER.
Something better (for some things systemd does) already exist, and people use it, and they are happy with it.
That however doesn't mean anyone who speaks against must write something that must replace it, be better than it. Ofcourse, it's hard to beat sense into the absolutist systemd crowd (there are tons of sensible people I interact with upstream, every one of those unlike you), but I am atleast trying my best.
That's it. Make something better and people will use it. People use Systemd not because it's perfect or the best design that could possibliy exist. They don't use it because Pottering forced them. They don't use it because of some evil conspiracy involving Redhat.
Red Hat hasn't been mentioned. You're here to pull that straw man again, paint the whole discussion as such, then go back and moan on twitter how much r/linux sucks, and people there have no sense.
It's the best that is available right now.
So was sysvinit, back in 2010? Quite the contrary, daemontools style supervisors offered better supervision infrastructure, ideas of which systemd itself has adopted (by being the parent of every daemon, hence exclusively tracking processes, or encouraging use of stderr to log stuff). People learn from prior art. We're still not there yet, there's scope for improvement.
Make something better and people will use it. Systemd and Debian and Fedora all proved that init systems are not something sacred. They can and are replaced. It happened in Solaris, it happened in Mac OS X, and it happened in Linux and pretty much any other Unix OS.
Ofcourse it isn't. At this point however, any technical discussion about systemd is raided by people like you, constantly trying to paint it with the same color - worst of all, diverting from the topic at hand. Why do you even bother?
Come back after taking some sleep.
21
I think what you don't understand is that systemd is software and when it has bugs it crashes.
I think what you're missing is that there are ways to mitigate those issues.
A smaller piece of software, as describe in the top comment, would likely have fewer bugs. This isn't saying "throw out systemd", it's saying "here's a way systemd could be modified to help prevent bugs like this in future".
20
Brilliant. Spot on.
I found a bug in Oracle that crashes the server.
I will now write my own version from scratch.
4
It's one thing about bugs happening, it's another thing to constantly ignore that one thing people have been pointing over the years, and also be passive aggressive "the kernel is so bloated, why do find systemd running as PID 1 a problem!?"
Though, I am not surprised. Some people are so pained by the cognitive dissonance that they will end up defending anything unreasonable.
32
the kernel is so bloated
Nobody said that.
Though, I am not surprised. Some people are so pained by the cognitive dissonance that they will end up defending anything unreasonable.
That's the only passive aggressive here. Also not constructive.
-3†
https://www.reddit.com/r/linux/comments/573z4i/comment/d8u7jn8
Also, seriously. Systemd's PID1 is trivial if you compare it with the kernel. The kernel is a huge blob of partly very questionnable code (think drivers!) all running in a huge single-address-space program running with highest privileges. but it is systemd's PID1 that you complain about?
Also, sorry about the last one, but it happens to be true that cbmuser has been chasing me around in this thread, and I am deeply frustrated going around answering the same thing to him. I have decided to not do that anymore, so it would be better for everyone.
27
Nobody said that.
Not today, yet. But cbmuser uses that argument all the time ... and so has Lennart.
18
So it's okay because everything else has problems?
26
we always need to have reference points
1
x.org is not a valid reference point for pid1
13
Just look at how many CVEs there were in ...
But can't the same argument be used as an excuse for any design flaws in any software?
25
[deleted]
1
Systemd is insecure by design. This is not about finding bugs in some processes but about knowing how to prevent them...
KISS
15
Obvious whataboutism. That's like saying 'safe languages have bugs, so I'ma keep using c for my business-critical application'. While ignoring the fact that it still prevents a whole class of bugs.
8
This is one of dumbest excuses ever seen.
2
[deleted]
0
CVEs themselves are not a sign of insecurity. Pushing opinions like that is what makes people refrain from filing CVEs when there is a security issues. You should be a LOT more worried if CVEs are not filed for projects.
4
The point is that we don't know how to make the kernel better. We know how to make the init better.
-5†
There isn't a consensus on how to make an init system that both supports the advancements in linux and is minimal enough to not overstep.
7
The point is that we don't know how to make the kernel better
We know, and there are better kernels: NT, QNX, seL4. Video driver shouldn't crash the whole system, only the rendering part, network driver shouldn't be able to write into the video memory etc.
3†
I gladly trade ability to crash with seriously better performance. Especially now as we have pretty much maxed out on per-clock performance and desperately try to scale using parallelism. When Tanenbaum and Linus debated this the situation was much closer to being favorable to microkernels because CPU:s truly got faster and they could assume they become fast enough soon.
And also a monolithic kernel can provide protection against crashes by limiting worker threads to a certain memory region in kernel space.
A Rust kernel is the only thing i can see displacing Linux because the security guarantee is a tangible benefit, but it will take immense amounts of work to arrive at them being functional on bare metal. This simply was not possible until today because Rust did not exist/was not ready for it.
0
Patch that fixes it: https://github.com/systemd/systemd/commit/612b74d32f970c43c14ad087ad086424792981b1
14
PR with additional fixes: https://github.com/systemd/systemd/pull/11754
11
The third big problem: Reboot to Upgrade
Wasn't this solved with daemon-reexec?
12
The article explains what's wrong with daemon-reexec.
16
Yeah except I read the article, and it doesn't?
-3
Yeah except I read the article, and it doesn't?
Ah, I see you cannot read then. Here's the relevant part:
With regards to upgrades, systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself, and continue uninterrupted. This could perhaps be used to switch to a new version without rebooting. Various programs already use this technique, such as the IRC client irssi which lets you /upgrade without dropping any connections. Unfortunately, this brings us back to the issue of PID 1 being special. For normal applications, if re-execing fails, the worst that happens is the process dies and gets restarted (either manually or by some monitoring process) if necessary. However for PID 1, if re-execing itself fails, the whole system goes down (kernel panic).
For common reasons it might fail, the execve syscall returns failure in the original process image, allowing the program to handle the error. However, failure of execve is not entirely atomic:
- The kernel may fail setting up the VM for the new process image after the original VM has already been destroyed; the main situation under which this would happen is resource exhaustion.
- Even after the kernel successfully sets up the new VM and transfers execution to the new process image, it's possible to have failures prior to the transfer of control to the actual application program. This could happen in the dynamic linker (resource exhaustion or other transient failures mapping required libraries or loading configuration files) or libc startup code. Using musl libc with static linking or even dynamic linking with no additional libraries eliminates these failure cases, but systemd is intended to be used with glibc.
In addition, systemd might fail to restore its serialized state due to resource allocation failures, or if the old and new versions have diverged sufficiently that the old state is not usable by the new version.
7
Not really, daemon-reexec only reexecs PID1. Restarting components like logind can still cause severe issues, depending on applications in use and the configuration. I've also lost network connectivity on networkd restarts a couple of times.
12
I was pointing to a very specific section of it, let's not stray from the topic at hand.
This time I quoted it, to be explicit, otherwise I will be accused of "flaming".
To be clear, Rich's example is too simplistic, you need to do a little more than that, but nothing to the capacity of what systemd does.
3†
[deleted]
1
I was actually just arguing with a GNOME developer recently about how the implementation of systemd was a bad idea and how I don't use GNOME because of how it relies on something so incredibly anti-unix-mindset.
This.
This is why.
This right here.
But instead legitimate gripes were downvoted to oblivion because systemd "just works."
10†
something so incredibly anti-unix-mindset.
This.
This is why.
This right here.
Your complaint is simply cargo culting. PID 1 crashing is irrelevant to the 'unix mindset'. You are posting FUD.
4
Do you not know what the Unix mindset is? Or what systemd is?
Because that's what it looks like...
-1
I'm well aware of both. In any scenario PID 1 is going to listen on the system bus. That's where this bug was located.
It's irrelevant to the unix mindset. No matter how small the daemon (and systemd is broken out into individual binaries in the unix tradition, although less than u/oooo23 would like)
1
I mean, this wasn't the first kernel panic caused by systemd is it?
6
The kernel always panics when PID 1 dies. It's arguably not the best behavior, but this never was much of a problem with the sysv init, which was very small and had very little functionality. People switched from sysvinit to upstart and now systemd, which make PID 1 much more complex, and the probability of hitting some bug and crashing is much higher.
22
maybe pid1 should die a lot , and its the kernel's fault if it panics ! after all , kernels should be wiser and more calm tempered :)
/s ( i thought it was a good joke ... :) )
0†
It's the third DoS CVE assignment.
7
[removed]
1
[removed]
-4†
This post has been removed for violating Reddiquette, trolling users, or otherwise poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended.
Rule:
Reddiquette, trolling, or poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended. Top violations of this rule are trolling, starting a flamewar, or not "Remembering the human" aka being hostile or incredibly impolite.
1
In case you missed it: systemd was a deeply controversial project, and it still hasn't stopped dividing the community.
If you're going to censor one side of the conversation, then at least make it official.
And, of course, the OP post would have to be censored as well.
2
I will continue to remove trolling comments regardless of subject matter.
4
I don't hate systemd politically, architecturally, conceptually, or any other way that people seem to. But damn, it is hard to stand up for it when the code quality is just appalling at times. This is not crusty ancient beast, or overcomplicated to death on the altar of portability, or a underfunded one-man project. Writing C code is difficult, yes, but by now we should be also fully aware of just how difficult it is and take that into account in the development.
44
But damn, it is hard to stand up for it when the code quality is just appalling at times.
The Linux kernel gets assigned anywhere between 10-15 CVEs about local DoS from both privileged and unprivileged users for every 1 DoS CVE assigned systemd. (3 CVEs for KVM alone just now in fact, one is a DoS). And probably 30-40 CVEs for every 1 CVE systemd has ever had since it's inception.
People are criticizing systemd harder for the fact that it's systemd.
66
You keep missing the point. This was avoidable. People pointed it out multiple times before.
28
The argument is "less code in PID1. It will crash!". My counter point is "this almost never happens". I'm very much on the point.
41
My counter point is "this almost never happens".
This sort of blase attitude toward bugs in PID 1 is a bit disturbing. PID 1 is kinda important after all.
24
Says the person using Arch ... where userns is disabled by default. Do you know why userns is disabled by default on Arch? Answer for others in case they don't know: It opens up a far-too-large privileged attack surface.
The only difference is that there are good reasons to run userns (to be able to run containers non-suid root ), whereas the only reason to have so much code in PID1 is laziness.
7
It just happened, ya know. Do you know why we are talking today?
You think you are on point, you miss the point entirely.
Neither of us agree, let's agree to disagree.
2†
I might have misunderstood.
Do you argument for ignoring a security vulnerability, because the conditions triggering it almost never happen?
1
Please, systemd has been hit by security vulnerability after vulnerability; there's a new one of this calibre every month.
-5†
The kernel is also a hugely complicated realtime system with thousands of developers, dozens of architectures, thousands of drivers, an infinite amount of permutations of configurations of peripherals, can operate on thousands of cores and on SoCs.
PID 1's job is to reap dead zombies.
27
PID 1's job is to reap dead zombies.
If you define the problem that way, but systemd has NEVER ascribed to that view, and it has been clear in not doing so.
If your view is that PID 1 should only be reaping dead zombies, then you have categorically rejected systemd's entire philosophy, and you shouldn't be running it.
10
> If your view is that PID 1 should only be reaping dead zombies, then you have categorically rejected systemd's entire philosophy, and you shouldn't be running it.
I would love to not be running it. Sadly, certainly people have worked very hard to not give me that option.
-2
PID 1's job is to reap dead zombies.
This can be moved out of PID 1. There are numerous service managers out there that do exactly that. Systemd even uses cgroups.
2
Linux is a kernel, and does much more security/memory management crap than a init system.
Also, a lot of it can be drivers.
18
People are criticizing systemd harder for the fact that it's systemd.
They are; but that doesn't change that systemd has reaped up a considerably higher number of vulnerabilities than the alternatives pretty much for the reasons people said it would: don't overcomplicated pid1 and don't rely on DBus.
This isn't just "bugs willl always happen" this is "bugs that could have easily been preventable have happened exactly for the reasons people said it would happen exactly for the reasons people criticized systemd's design on snice it was unveiled"
Now what is true is that systemd is the only thing Red Hat vomited up that gets this level of criticism. The truth of the matter is that DBus, PulseAudio, NetworkManager, upower, polkit and all the other Red-Hat-isms that are basically designed to make Unix more familar to Windows users are filled with similar bugs and security concerns for similar design reasons because it turns out that if you copy Windows-like design you inherit a lot of its problems.
15
has reaped up a considerably higher number of vulnerabilities
systemd has gotten 13 CVEs since 2010. That is not a high number.
16
Ehh, source? systemd has 33 here.
Compare Upstart having 2, OpenRC at 2, Runit at 1.
Fun fact Xorg has 36 and is basically twice as old as systemd and this is a program that for historical reasons had to be setuid for a long time
18
Linux makes my hardware work. It is millions of lines of code. It is the largest open source project in existence.
systemd offers nowhere near as much value as Linux to me. Furthermore, its scope is far more limited than that of the Linux kernel.
9†
Yes, which is why it has a extremely low CVE count considering what it does, and how widespread it is.
23
That's a really bad excuse when the criticism on systemd is exactly what it does and that it shouldn't be doing that which in no small part is re-inventing the functionality of mature battle-hardened software which already exists of which people right now have reasonable confidence it does not contain such bugs but then systemd comes along and rewrites in a couple of months the functionality of various things that have existed and for 10 years now whose major bugs are already ironed out and presses it for release then.
Don't replace what works with brand new code written from scratch that is barely tested just because of NIH-syndrome.
12
considering what it does
What doesn't systemd do nowadays?
extremely low CVE count
The Linux kernel is ~20mil loc. Systemd is ~1mil loc. Let's take those values.
Given the stats you cited above, systemd has a higher incident of CVE per loc than the kernel.
This is especially troubling since chance for bug/vulnerability increases exponentially with code size.
3†
Please don't yell.
-6†
It is millions of lines of code.
Linux is 20m, systemd is 1m. Considering the amount of CVEs they does not seem that different.
14
Wow didn't know systemd was so big now. While you have a point about size, I would argue the nature of systemd code is less challenging and error prone than working directly with hardware.
The truth is that systemd puts on a lot of interface, and that is just a fancy word for attack surface.
I dare you to strip it down.
3†
[removed]
-5
This post has been removed for violating Reddiquette., trolling users, or otherwise poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended.
Rule:
Reddiquette, trolling, or poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended. Top violations of this rule are trolling, starting a flamewar, or not "Remembering the human" aka being hostile or incredibly impolite.
1
You wouldn't happen to know if SystemD hasn't yet grown to have more lines of code than the linux kernel would you?
And you realize that's an apples to oranges comparison?
-11
Ah yes. Of course the person writing "SystemD" wants to call out "you are comparing apples to oranges!".
Sure, we are comparing apples to oranges. But we are talking about DoS vulnerabilities after all. The outcome is the same for both; the kernel crashes.
The argument against systemd as many like to mention, is that a larger code base in PID1 leads to crashes. Why is this important? Because the kernel can't recover. So we are not comparing the kernel, and systemd explicitly anymore.
16
You NEED the kernel. You don't NEED SystemD.
The kernel can't be designed in a more resilient way the way an init can be designed.
It's an apples to oranges comparison and you know it. I mean, I assume you do. You support SystemD, so I have to wonder...
-11
This is more a design decision causing problems, and it isn't that this hasn't been pointed out the first time.
See https://www.reddit.com/r/linux/comments/573z4i/comment/d8u7jn8
lennart-poettering • 2y On UNIX PID 1 is special. It will get SIGCHLD events for all processes whose parents died. It will get special system events such as ctrl-alt-del and a number of others. That means that code such as the service lifecycle management and process reaper code really belongs into PID 1. Of course you could also move the state engine for that into PID 2 and make PID 1 just a shim that propagates to PID 2, but never forget that IPC makes stuff more complex than no IPC. Moreover nothing is actually won by that besides the added complexity: if pid2 dies the system is not usable anymore. Which is exactly what happens if pid1 dies now, since we actually install a handler for SIGSEGV and SIGABRT which makes sure to simply freeze pid1 in this unlikely case rather than let pid1 exit and thus hang the kernel and system as a whole.
Also, seriously. Systemd's PID1 is trivial if you compare it with the kernel. The kernel is a huge blob of partly very questionnable code (think drivers!) all running in a huge single-address-space program running with highest privileges. but it is systemd's PID1 that you complain about?
Lennart
His concerns about SIGCHLD are solved by making systemd --system a subreaper, nothing else is valid (and the last argument is bogus, the kernel is bloated and does everything, why not also put journald and udevd and logind because you can?).
For those special events forwarded to PID 1, a simple pipe where the read end is given to systemd --system and single bytes to denoting those written by dumb PID 1 to the write end on reception of signals can be used to achieve what it does today.
However, the goal should be minimize as much as possible to do in PID 1.
18
Your argument hinges on the assumption that making systemd restartable, preferably with less impact than rebooting the whole system, is easy or even possible. I don't see that as such a given; indeed I can fairly easily imagine it being very difficult thing to do
7
Have you heard of systemctl daemon-reexec? PID 1 serializes its runtime state to a memfd and executes into the new PID 1, rebuilding its state from it again, and coming back to responding to events by entering the main loop.
Upstart did something similar.
13
PID 1 serializes its runtime state to a memfd and executes into the new PID 1, rebuilding its state from it again, and coming back to responding to events by entering the main loop.
That is very fine and dandy if you are doing a controlled restart from a known-good state. Which is very different from restarting a crashed process that might have very well been in some sort of error state or it wouldn't have crashed in the first place.
8
For those special events forwarded to PID 1, a simple pipe where the read end is given to systemd --system and single bytes to denote those written by dumb PID 1 to the write end on reception of signals can be used to achieve what it does today.
I just spawn an executable. Seems way easier to coordinate, and it is a more flexible mechanism in my opinion. The events (SIGINT and SIGPWR for my init) are infrequent enough to not care about the performance hit of a fork() and exec()
FWIW I don't think the init should do any supervision or process restarting. You get into code path duplication issues there, and process restarting is not always desired. Most of the time PID "2" (it will probably be far larger with an initramfs) will never need to be restarted, and a reboot should just be done.
7
[deleted]
0†
However, the goal should be minimize as much as possible to do in PID 1.
May I ask which projects you have contributed yourself so far?
If you are so convinced that you know how it’s done properly, why aren’t you working on an alternative yourself or make suggestions and submit patches to systemd?
-12
I have contributed to systemd (this and the next release). I fixed multiple bugs in the transaction computation code. PM me and I will link you all my patches (and bug reports).
16
I wasn't aware that patches to open source software were so private that you can't just put them as a comment and they need to be in PM form. Multiple people in this thread have asked you for links to your patches, why not just put them in a comment and link that?
-4
May I ask which projects you have contributed yourself so far?
That's always your bluff. And when someone comes back and provides them, you shut up. You'll note he had a patch to the latest systemd release.
The fact is that your "question" is really an ad-hominem attack in disguise --- you're trying to attack the person, and not his comment or ideas. It completely ignores the issue and constructive comment about how it can be avoided.
Just stop.
12
Probably because adoption is just as important as implementation. Somebody needs to do the politicking... especially with you in every thread heckling and diverting.
8
I am still waiting for it.
8
Yeah, I didn't have a preference, one way or the other, but when Ubuntu defaulted to systemd, my system went from taking 30 seconds from power-on to login to several minutes. I figured out how to set grub to boot with upstart, which brought everything back to normal, but after a few years Ubuntu wouldn't load XFCE, without systemd running, so I switched back to FreeBSD.
If it just worked well, I wouldn't have noticed it's existence, but now I don't like it.
4
If it just worked well, I wouldn't have noticed it's existence, but now I don't like it.
Sounds like Ubuntu screwed up their systemd integration, like they have with so many other projects..
1
when the code quality is just appalling at times
But of course this was just one of the many criticisms: the people behind it are not fit to build mission-critical infrastructure, and they're going to take over unrelated parts of the Linux ecosystem, and cause lock-in up to the application level.
And exactly these things happened, and it's going to get a lot worse.
0
Indeed. C is a straight razor, it's hard for a reason and shouldn't be placed in inexperienced hands.
There's nothing wrong with C, what's mostly wrong is the way it's taught at school - if taught at all.
-1†
no, there's something wrong with C
7
Then C++ and Rust's unsafe keyword have something wrong with them...
3
Rust's "unsafe" is a giant flashing neon sign saying "audit me extra super carefully".
And apart from that, if you do experience a memory safety bug, you can immediately narrow it down to 3% of your codebase, and then proceed from there.
6
yeah, C++ is fucked.
and double yeah, that's why unsafe is called unsafe and it's recommended you minimize its use at all costs (and rust's developers keep working to make needing to use it less necessary).
4
There are a lot of things wrong with C. Variable-length arrays, for starters.
Curiously, VLAs are the very thing that caused this bug. They are a misfeature and have been removed from the standard for many good reasons. You should not use them.
7
[deleted]
3
Should have been written in rust.
20
That wasn't viable when systemd started. Systemd had its initial release 4 months before Rust appeared. However, given where it sits in the stack, maybe they should start porting it over.
8
[removed]
1
VLAs strike again!
They may look neat and they are tempting to use, but without any way to check the available remaining stack size they are just as bad as strcpy
13
Yeah I think Linux got rid of all VLAs a while ago.
2
I just got my linit running on metal yesterday :)
9
I genuinely don't get why so many people are so opposed to systemd. Isn't the whole beauty of linux that you get to choose something like this, and you're not stuck with one thing? This is like a Fedora user getting mad that Ubuntu is changing something in their latest release...
8
Isn't the whole beauty of linux that you get to choose something like this, and you're not stuck with one thing?
Yes, it is. However, systemd is becoming something that you can't replace, something that we all just have to grin and bear. Systemd is betraying the very flexibility that allowed it to gain a toehold by positioning itself to be irreplaceable.
4
So don't use a distro that uses it. One of the best parts of Linux is that you actually have that option! Hell, if systemd is the kinda thing that bothers you but you like your current distro I'm pretty sure Bedrock lets you replace the init system while keeping the rest of the distro intact. As long as there are people interested in the Linux community, everything will always have an alternative.
7
All of the major distros run systemd at this point. That means more and more software will be written with the assumption that systemd is installed, and that software will start to depend on systemd-specific mechanisms to work. Look at Gnome, for example.
As long as there are people interested in the Linux community, everything will always have an alternative.
Systemd's ambitious and sprawling goals make this not so sure anymore.
6
I also still don't quite understand the major problem with systemd. I get that people don't want it to be the only option, but beside that what's exactly wrong with it? This is coming from a complete noob so sorry if this is a kinda stupid question.
7
All of the major distros run systemd at this point.
You think there might be a reason for this? And no, it's not some vast conspiracy.
2
The issue with systems is that it's trying to take over every single task. Networking, sessions, dbus, boot, etc. The developer also has a serious attitude issue over design quality and bugs. For one binary logging is just obnoxious and counterintuitive. It also has has issues keeping my user logged in even though I logged out so my ecrypted home stays wide open just begging for anyone who is wheel/root to see my files. Bug report says they're not in the business of fs mounting, however their supplied unit file to unmount at logout just doesn't work. There's also the rw mounted efi vars but that's a whole another story.
2
There's also the rw mounted efi vars but that's a whole another story.
Please don't spread FUD, that was a kernel bug. Kernel devs came forward to own it because so much FUD was spread.
Also the rest of what you posted seems to be random speculation with no attempt to look into it.
4
Please don't spread FUD, that was a kernel bug. Kernel devs came forward to own it because so much FUD was spread.
2
Thanks my dude.
1
The issue with systems is that it's trying to take over every single task. Networking, sessions, dbus, boot, etc.
Most of the tools of the systemd project are optional. For example, nobody forces you to use systemd-networkd. On my notebook, for example, I use netctl for the network connections without any problems.
For one binary logging is just obnoxious and counterintuitive.
For me, the advantages outweigh the disadvantages. The log file queries have become much easier in my opinion (for example journalctl --since="2012-10-30 18:17:16" or journalctl -p err..alert or journalctl -u unbound.service).
If one does not want binary log files, simply install syslog-ng. The log files will then be available in text format again.
1
This is like an Arch user getting mad because Ubuntu or Fedora are changing something in their distros....oh wait....
Why would I care?
1
I just changed the wording of that to be a little clearer to what I meant.
1
I guess I was a little awkward about the way I phrased myself. I wanted to say that I can't understand it when a user of Distribution A gets upset about what is happening in Distribution B. For example, I like to use systemd. But I have no need to make fun of distributions that don't use systemd. When I find the time, I even want to take a look at Alpine, for example.
2
I always read all this threads, I learned a lot from it.
3
[removed]
2
This post has been removed for violating Reddiquette, trolling users, or otherwise poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended.
Rule:
Reddiquette, trolling, or poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended. Top violations of this rule are trolling, starting a flamewar, or not "Remembering the human" aka being hostile or incredibly impolite.
1
[deleted]
2
[removed]
1
Oh so thaaat's what's doing it.
1
Sure woul be nice if that page actually let you read the full text, instead of truncating it like it's on some crappy terminal from the 70s.
1
I'd just like to interject for a moment. What you’re referring to as systemd, is in fact, NSA/systemd, or as I’ve recently taken to calling it, NSA plus systemd. systemd is not an init system unto itself, but rather another free component of a fully functioning NSA system made useful by the NSA backdoors and broad buggy system that touches as many components as possible and runs at PID 1. Many computer users run a modified version of the NSA system every day, without realizing it. Through a peculiar turn of events, the version of the NSA backdoor which is widely used today is often called “systemd”, and many of its users are not aware that it is basically an NSA rootkit, developed by the NSA and forced onto the Linux community with their public shell company Red Hat. There really is a systemd, and these people are using it, but it is just a part of the backdoor they use. systemd is the kernel or host: the software the NSA backdoor resides in that collects all your private data. The host software is an essential part of an NSA backdoor, but useless by itself; it can only function in the context of a complete rootkit. systemd is normally used in combination with the NSA operating system: the whole system is basically NSA with systemd added, or NSA/systemd. All the so-called “systemd” distributions are really distributions of NSA/systemd.
1
[deleted]
1
Everyone switch to runit fasta
0
[removed]
-3†
This post has been removed for violating Reddiquette, trolling users, or otherwise poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended.
Rule:
Reddiquette, trolling, or poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended. Top violations of this rule are trolling, starting a flamewar, or not "Remembering the human" aka being hostile or incredibly impolite.
1
[removed]
-4
This post has been removed for violating Reddiquette, trolling users, or otherwise poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended.
Rule:
Reddiquette, trolling, or poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended. Top violations of this rule are trolling, starting a flamewar, or not "Remembering the human" aka being hostile or incredibly impolite.
1
[deleted]
-9
What if he doesn't? Will you reverse your opinion then?
10
[deleted]
-4
No doubt Poettering will say it's all the fault of d-bus.
You’re referring to the Lennart Poettering who is credited with helping fix this issue in the linked post? You’re deluded.
6
Why is everyone hating on poor systemd
-9
[removed]
10
[removed]
systemd discussion honestly is about on par with YouTube comments
This post has been removed for violating Reddiquette., trolling users, or otherwise poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended.
Rule:
[deleted]
Don't take all the popcorn for yourself, sharing is an important part of open source. Which is why I get all of it.