Cook: security things in Linux v5.1 [LWN.net]

Cook: security things in Linux v5.1

Posted May 29, 2019 18:35 UTC (Wed) by epa (subscriber, #39769) [Link] (6 responses)

Is it possible to use the new race-free signalling in shell scripts?

Cook: security things in Linux v5.1

Posted May 29, 2019 19:14 UTC (Wed) by josh (subscriber, #17465) [Link] (5 responses)

Not today, but if you had helper programs for it, sure. You could modify coreutils `kill` to accept an fd number, for instance, and then pass it a pidfd via redirection. And you could modify the shell or create a helper program that spawns a process and gives you a pidfd, or obtains a pidfd for an existing process for you. (In the latter case you'd want to check it before using it.)

Cook: security things in Linux v5.1

Posted May 30, 2019 3:26 UTC (Thu) by wahern (subscriber, #37304) [Link] (2 responses)

I assume `exec 3</proc/$pid` would work to acquire a handle in the shell, but I haven't tested it.

Cook: security things in Linux v5.1

Posted May 30, 2019 15:43 UTC (Thu) by mgedmin (subscriber, #34497) [Link] (1 responses)

Don't you need to open it with the O_DIRECTORY flag? I don't think shell redirection will pass it.

Cook: security things in Linux v5.1

Posted May 30, 2019 16:21 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

No, the O_DIRECTORY flag just causes the open() call to fail if the path does not refer to a directory. You can open directories without it. The shell has no issues redirecting from a directory rather than a file. You can test that yourself easily:

$ ls -l /proc/self/fd 3</etc
total 0
lrwx------ 1 user group 64 May 30 11:16 0 -> /dev/pts/N
lrwx------ 1 user group 64 May 30 11:16 1 -> /dev/pts/N
lrwx------ 1 user group 64 May 30 11:16 2 -> /dev/pts/N
lr-x------ 1 user group 64 May 30 11:16 3 -> /etc/
lr-x------ 1 user group 64 May 30 11:16 4 -> /proc/NNNN/fd/

Cook: security things in Linux v5.1

Posted May 30, 2019 4:53 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Are fd numbers safe against reuse? (If the process dies in the meantime, might not the same fd number be used for some other file, or even an unrelated process?)

Cook: security things in Linux v5.1

Posted May 30, 2019 5:00 UTC (Thu) by epa (subscriber, #39769) [Link]

Sorry, an fd number means the number of an already open file handle, so 0 for stdin, 1 for stdout and so on. This is obviously race-free once opened. But how to open the fd safely?

Cook: security things in Linux v5.1

Posted May 29, 2019 21:01 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (20 responses)

The pid needs to be known to open /proc/$pid. Unless the process doing the open is the parent of the process referred to by the process ID, there's no way to determine if the process the pid originally referred to is still the process it's referring to at the time of the open. As was discussed elsewhere, in the context of the "kill some processes most of which were hopefully supposed to be killed"-shotgun pkill, it's possible to derive a justification for killing a process by examining the contents of the /proc/$pid directory after the open. But this is really just for blame-shifting as pkill will continue to kill an essentially random set of processes which happen to be so unfortunate to run while pkill is looking for processes to kill.

Cook: security things in Linux v5.1

Posted May 29, 2019 21:15 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

> Unless the process doing the open is the parent of the process referred to by the process ID, there's no way to determine if the process the pid originally referred to is still the process it's referring to at the time of the open.
What is this obsession with the parent process?

Here's pseudocode for absolutely reliable pkill:

 processes = listProcesses(filter=lambda n: n.name == target)
 for p in processes:
    pidfd = pid_open("/proc/%d", p.pid)
    if hasProcess(name=target, pid=p.pid): // Check that the invariant still holds
       pidfd_kill(pidfd, SIGKILL)
    close(pidfd)

It's guaranteed only to kill processes with the name matching the "target" name.

Cook: security things in Linux v5.1

Posted May 29, 2019 21:51 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (12 responses)

What's your problem with this simple fact? Using your pseudocode as example, it's impossible to determine if a pid in the processes list still refers to the process found by listProcesses by the time of the open.

Putting this in another way, processes with the given name which are started after listProcess returned and before the loop terminates will only be killed if they happen to reuse a pid which hasn't already been used in the loop.

Cook: security things in Linux v5.1

Posted May 29, 2019 21:54 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

> What's your problem with this simple fact?
Because you're stupidly wrong?

My code does exactly what the contract of pkill is: killing processes by name.

> Putting this in another way, processes with the given name which are started after listProcess returned and before the loop terminates will only be killed if they happen to reuse a pid which hasn't already been used in the loop.
This is true with ANY variant of pkill. A matching process can be started at the moment pkill exits and it'll be missed.

Yet my code guarantees that any matching processes that existed before the pkill launch will be killed.

Cook: security things in Linux v5.1

Posted May 29, 2019 23:50 UTC (Wed) by ms-tg (subscriber, #89231) [Link] (9 responses)

I’m wondering why the race condition question here is attracting such uncollegial responses (“obsession”, “stupidly”)?

My understanding of the race condition being asked about:
1. listProcesses is called. Imagine it atomically returns a set of (name, pid) tuples alive at the time of the call

2. a process with name: “foo” and pid: 42 is filtered by the lambda from that list

3. This process exits. A new process named “dont_kill_me” is started and received recycled pid 42

4. The pid fd for 42 is opened. It refers to dont_kill_me

5. This new process is killed

I’d be super interested in learning more about:

(a) does the pseudocode as presented actually avoid suffering from this race, and how?

(b) is there something offensive about asking about this?

Thanks!

Cook: security things in Linux v5.1

Posted May 29, 2019 23:57 UTC (Wed) by ms-tg (subscriber, #89231) [Link] (1 responses)

Also: my understanding of why parent process was mentioned by the original poster, is that an assumption is being referred to that only the parent process can racelessly acquire the pid. Any other process would be racing to get the pid, and open the pidfd from it, before it could die and be recycled.

Is that context correct? At least that’s the inference I made about the relevance of a parent process.

Cook: security things in Linux v5.1

Posted May 30, 2019 12:55 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link]

Yes, this is correct.

[verbal redundancies due to LWN blocking 'yes' as an answer ...]

Cook: security things in Linux v5.1

Posted May 30, 2019 0:05 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> I’m wondering why the race condition question here is attracting such uncollegial responses (“obsession”, “stupidly”)?
Because rweikusat2 seems obsessed with insisting that the old Unix API is the only source of truth.

> (a) does the pseudocode as presented actually avoid suffering from this race, and how?
Yes. Imagine that one of the initially matched processes dies and is replaced by another process.

In this case the pid_open() call will return the handle to that incorrect process. However, this is fine because the next check for checkProcess() will fail and nothing is going to be killed.

If this check does succeed then there are two options:
1) The new process also matches the target name and so it's OK to kill it (according to pkill's contract).
2) The new process has actually died in the time between the pid_open and checkProcess, and it's been replaced by a new process that matches the target. In this case the further pidfd_kill() call will be a no-op (since its target is dead), but this is still fine within the pkill's contract.

> (b) is there something offensive about asking about this?
No.

Cook: security things in Linux v5.1

Posted May 30, 2019 9:36 UTC (Thu) by moltonel (guest, #45207) [Link]

> Imagine that one of the initially matched processes dies and is replaced by another process.
>
> In this case the pid_open() call will return the handle to that incorrect process. However, this is fine because the next check for checkProcess() will fail and nothing is going to be killed.
>
> If this check does succeed then there are two options:
> 1) The new process also matches the target name and so it's OK to kill it (according to pkill's contract).
> 2) The new process has actually died in the time between the pid_open and checkProcess, and it's been replaced by a new process that matches the target. In this case the further pidfd_kill() call will be a no-op (since its target is dead), but this is still fine within the pkill's contract.

Might as well not do the initial matching then ? Just go through the unfiltered process list, open /proc/<pid>, match using content of /proc/<pid>/, and kill if it matches ? I imagine performance cost of opening /proc/<pid> is dwarfed by the general cost of process matching ?

The commit message doesn't say clearly whether "the entire procfs directory remains visible or just one entry" when /proc/<pid> is opened (it says "same as happens right now" but I don't know what that is). I'm tempted to understand that the whole directory remains visible (otherwise the patch only barely reduces the RC window), but at the same time the message says that opening /proc/<pid> doesn't reserve the pid, so I wonder.

Cook: security things in Linux v5.1

Posted May 30, 2019 12:07 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (4 responses)

There's actually a third option: The program running in the process which matched the search criteria during the second check does an exec and thus, turns into a process which shouldn't have been killed, before the signal is being sent. This causes the contents of a /proc/$pid directory to change in-place, as can be trivially tested by doing an exec of 'something suitable' from a shell.

It's probably possible to prevent this somehow but at least, this wasn't mentioned so far.

Cook: security things in Linux v5.1

Posted May 30, 2019 16:12 UTC (Thu) by FLHerne (guest, #105373) [Link] (3 responses)

I don't see that as an issue - the process should have been killed at the time `pkill` was started; it might as well have been killed moments *before* changing, e.g. with scheduling differences or if `pkill` was a little faster.

Cook: security things in Linux v5.1

Posted May 30, 2019 17:21 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

The process should have been killed if the pkill algorithm would work. Which would require freezing the system until the program is done examining the process list. As it cannot do this, it's just another process pkill shouldn't have killed as it didn't match the selection criteria: This utility is inherently broken/ unreliable.

Cook: security things in Linux v5.1

Posted May 30, 2019 22:57 UTC (Thu) by cyphar (subscriber, #110703) [Link] (1 responses)

pkill today might kill a process like this. You're describing a fundamental race condition in the contract of pkill -- "kill all processes with this name" obviously has a probabilistic chance of killing a process that is in the middle of changing its name. I highly doubt that any user of pkill wants the contract that you're claiming they want.

Also, pkill is a toy example. The real users of this syscall are more complicated systems which are sure that the pidfd is correct, and need to store it somewhere so they can detect the process dying properly (and send it signals if its not dead). Container runtimes and init systems are obvious contenders.

Cook: security things in Linux v5.1

Posted May 31, 2019 17:28 UTC (Fri) by rweikusat2 (subscriber, #117920) [Link]

I didn't write anything about "processes changing their name" (that's a prctl operation) or "processes in the middle of something". I wrote about pkill killing a process it shouldn't have killed because the program running in this process changed after pkill had selected it for killing but before sending a signal to it. That's a second TOCTOU race which is indeed -- as I already wrote - inherent in the pkill algorithm[*]. For a reliable pkill, ensuring that the pid is still valid isn't sufficient because the process can change as well.

I also didn't come up with the pkill example, I made a general statement about pidfd open calls in absence of some guarantee that the process the pid originally referred to didn't terminate in the meantime. pkill was presentend as an example where one can claim that the race wouldn't matter in practice for more or less good reasons.

[*] Both the "process terminates and pid gets reused" and the "process starts to execute a different program" races could be avoided without any new system calls by sending a SIGSTOP to a process before checking its attributes, BTW.

Cook: security things in Linux v5.1

Posted May 30, 2019 0:38 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link]

I do not dispute your unrelated statement.

Cook: security things in Linux v5.1

Posted May 29, 2019 21:33 UTC (Wed) by sbaugh (guest, #103291) [Link] (5 responses)

I think the thing you're neglecting in your explanation, which is causing the confusion and disagreement between you and other commenters, is that choosing which processes to kill based on their names is a bad idea *even if the selection is perfectly reliable*.

Using pkill to kill processes based on name is a *bad idea*, and it's always been a bad idea, and it remains a bad idea even with pidfd_send_signal. There's nothing preventing some random other process from having the same name and getting caught up in your killing spree.

From this standpoint, you're completely right that the now "reliable" pkill is still essentially random.

The real benefit of pidfd requires coordination with the parent of the process, as you say.

As one example: pidfds can be passed around over Unix sockets, so a process can spawn a child, pass the pidfd for that child to some other supervisor process, and exit. This supervisor process then can actually kill the child process without having a race condition! This can be provided as a service to the rest of the system as well - rather than reading a pid out of a pidfile and killing it, or using pkill to kill all processes with a specific name, I can contact some supervisor and say, "kill this process", uniquely identified via whatever means. I could even ask the supervisor to give me the pidfd, and do the killing myself!

But all this reliability still requires coordination with the parent at start time. Otherwise it's not possible for me to uniquely identify that specific process, no matter how unique I make the name, plus the executable, plus whatever else.

Cook: security things in Linux v5.1

Posted May 29, 2019 21:54 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

That's (selection by name isn't specific enough) an additional problem. What I meant by 'random' is that processes matching the search criteria which are started while pkill is executing may or may not be killed by pkill.

Cook: security things in Linux v5.1

Posted May 29, 2019 23:03 UTC (Wed) by roc (subscriber, #30627) [Link] (1 responses)

Cyberax pointed out that only specification for pkill that makes sense is "all matching processes *which started before pkill* have been signaled or died".

The specification "all matching processes 'which started before or while pkill is executing' have been signaled or died" is silly because it can't be implemented: in general a matching process could start at the moment just before pkill calls exit(). It's also silly because it's useless: a matching process could start the moment *after* pkill calls exit(), so you couldn't depend on no matching process running.

Cook: security things in Linux v5.1

Posted May 30, 2019 0:35 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link]

... and possibly some number of other processes. But we can blame someone else for that!

Cook: security things in Linux v5.1

Posted May 29, 2019 22:51 UTC (Wed) by roc (subscriber, #30627) [Link] (1 responses)

In practice killing things by name is completely reliable in many cases. For example I may `pkill ^gdb$` in an environment where I actually do know that the only running gdbs are those I started myself. And in that case, using pidfds closes a potential race where a gdb dies (e.g. because of OOM which is why I'm trying to kill it in the first place) and some innocent new process gets killed.

Cook: security things in Linux v5.1

Posted May 29, 2019 23:41 UTC (Wed) by sbaugh (guest, #103291) [Link]

Killing things by name is completely reliable only in trivial systems - admittedly, many systems are trivial. As soon as there's any software running on the system whose behavior is not totally known, killing things by name becomes unreliable. Why shouldn't my complex application with a bunch of state, say, start a gdb attached to itself if it hits an error? Or an IDE, certainly, might start gdb spontaneously.

I do use pkill myself on my dev boxes, but let's not pretend pkill is a good way to do things. It's a stopgap measure that we use only because the process supervision mechanisms on Unix are insufficient. I think it's entirely possible that with further development of pidfd, along with various other mechanisms, we can replace pkill with more reliable, powerful, and easier to use tools.

For example, perhaps a tool that kills all the processes started from this terminal or its children, even if those processes have been reparented to init, called setsid, or whatever. That would solve pretty much all the cases I use pkill for.

Cook: security things in Linux v5.1

Posted May 31, 2019 23:01 UTC (Fri) by peda (subscriber, #5285) [Link] (16 responses)

regarding "ongoing: implicit fall-through removal", there is a suggestion that one should look up all the "missing break" patches, with a link to an impressively long list of patches. But. Most of them are about adding or fixing the spelling of "fall through".

Fixing the spelling in a comment (or adding a comment) is not precisely the same thing as a patch for a "missing break" in my book...

Cook: security things in Linux v5.1

Posted May 31, 2019 23:11 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

The comment has special meaning to GCC and therefore fixing the spelling or adding a comment makes it possible to compile it with the appropriate switch so that there are no missing breaks accidentally added in the future. That's the purpose of these patches.

Cook: security things in Linux v5.1

Posted Jun 1, 2019 7:02 UTC (Sat) by peda (subscriber, #5285) [Link] (1 responses)

Of course. But your comment has very little to do with me calling out the misrepresentation.

The description made it sound like the full list was patches fixed real bugs resulting from all the boring work, when in fact most of the patches /are/ just the boring work. Only a fraction of the patches fix real bugs. It is far more interesting to see the fruition of the boring work, rather than the work itself.

Cook: security things in Linux v5.1

Posted Jun 3, 2019 22:30 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

> It is far more interesting to see the fruition of the boring work, rather than the work itself.

I fundamentally disagree with this as well as the notion that there was any misrepresentation. It is great to see all the work being done.

Cook: security things in Linux v5.1

Posted Jun 3, 2019 22:02 UTC (Mon) by bnorris (subscriber, #92090) [Link] (12 responses)

I didn't look through every commit that was linked, partly because that search shows all commits mentioning "missing break"...for all time. But:

* restricted to v5.0..v5.1, I only found a single commit that fixed spelling:
09186e503486 security: mark expected switch fall-throughs and add a missing break
but it also adds a missing break. There weren't many other "missing break" patches in that range.
* another arbitrary sampling of those commits turned up zero spelling fixes.

What "most" are you looking at?

Cook: security things in Linux v5.1

Posted Jun 4, 2019 17:59 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (10 responses)

"Most" of the patches from the person working on this: They're about adding comments to perfectly working code in order to "convince" a compiler that the code was indeed written as it was meant to be written. Which is as redundant as it could possibly be. This 'warning' is still nothing but a political statement about a certain C feature.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 18:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

Your message is nothing but a political statement in favor of unreliable crashy systems.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 18:51 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (8 responses)

Assuming your assertion was correct, Linux ought to have been "an unreliable, crashy system", whatever that's supposed to mean precisely, prior to introduction of this "security innovation" because it should have uncovered a huge number of missing breaks. Instead, it 'uncovered' that the vast majority of of switch cases without break were correct.

That's a statement-of-fact whose content you may not like but it's not going to change because of this.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 18:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> Assuming your assertion was correct, Linux ought to have been "an unreliable, crashy system"
And it is.

> Instead, it 'uncovered' that the vast majority of of switch cases without break were correct.
And a lot of incorrect ones. So actual bugs were fixed and a mechanism to prevent this entire class of bugs has been instituted. Moreover, it's completely zero-cost at runtime.

At this point any opposition to this feature is basically boneheaded politics.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 19:53 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (5 responses)

If that's you honest belief (about Linux), you would be well advised to stay clear of it. Let other people deal with this mess, given its undisputable technicalt shabbiness, it'll vanish on its own. There's no way anyone will ever use it for anything serious!

As to the "feature": As I already wrote when this nonsense came up for the last time, the sensible way to handle this situation would be to add a multiway conditional without fallthrough to the language. This would do away with the need to use break at all unless one specifically needs fallthrough, thereby actually eliminating the problem. Eliminating the default policy of the existing construct just means more text to type for programmers, thus increasing and not decreasing the likeliness of compile-time errors while changing absolutely nothing about run-time errors as both variants can always be used incorrectly. This will still need testing and code-audits.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 20:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> If that's you honest belief (about Linux), you would be well advised to stay clear of it. Let other people deal with this mess, given its undisputable technicalt shabbiness, it'll vanish on its own. There's no way anyone will ever use it for anything serious!
You clearly have a rosy view of the world. In the real world out here, Linux crashes quite easily by running perf fuzz tests, for example. Or you can look at the never-ending list of CVEs.

The only realistic way to have reliable systems is to plan for failure and make sure that the system can fail safely.

> As to the "feature": As I already wrote when this nonsense came up for the last time, the sensible way to handle this situation would be to add a multiway conditional without fallthrough to the language.
This is not a realistic option.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 21:31 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (3 responses)

> You clearly have a rosy view of the world. In the real world out here,

You should perhaps consider jettisoning the "discussion tactic" of asserting that whoever disagrees with one of your opinions must be "somehow mad". This not only ought to qualify as abusive, it also really just communicates that you have no arguments in favour of your standpoint and thus, prefer attacking people who disagree with it. In the real word, not in the fuzztesting playpen, Linux has a well-deserved reputation for reliability and that's why it's ubquitiously being used. For instance, in Android phones. Like any other complex programs, it also has bugs.

Considering that the fallthough comment overload is a language extension, adding a language extension adressing what's claimed to be the actual issue is obviously possible. It may not be a realistic option for ISO-C but Linux uses lots of language extensions already. I would wholeheartedly welcome this as it would eliminate the need to write lots of break-statements for the most common case. In contrast to this, forcing people to write yet more semantically pointless text in order to get a program through the compiler just means "more syntax errors beause of typos", as I already wrote.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 21:57 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Linux is reasonably reliable when compared to other mainstream general purpose operating systems. That's a far cry from asserting that Linux is fundamentally reliable by any absolute metric - running even a naive fuzzer against Linux will demonstrate a large number of bugs, many of which are due to C being a language that makes it extremely easy for people to fuck up. And yes, I'll gladly take "more syntax errors because of typos" if doing so means that it's unambiguous what a developer intended.

Cook: security things in Linux v5.1

Posted Jun 7, 2019 0:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> In the real word, not in the fuzztesting playpen, Linux has a well-deserved reputation for reliability and that's why it's ubquitiously being used.
Yeah, it's so great that Google is now developing a whole new OS.

I've worked with Linux a lot, working with clusters with hundreds of thousands of nodes and Linux failures were commonplace. OOPSes, hangups, livelocks, you name it. So yes, Linux is not reliable.

This is fine, engineering is a science of building reliable components from unreliable parts. You just have to plan for the worst case.

> Considering that the fallthough comment overload is a language extension, adding a language extension adressing what's claimed to be the actual issue is obviously possible.
OK. So let's see how it would work.

First, we need to find a new keyword (not easy in itself) to replace "switch". Let's settle on "new_switch". This construction will require "fallthrough" keywords (again...) at the end of cases.

How do we deploy it? Linux supports quite old compilers, so you can't just mandate GCC 11 for it. Well, macros come to rescue. There's going to be a #define for the switch statement and then a #define for the fallthrough. And then you'll have to change ALL the statements in Linux to use the new statement, resulting in an even bigger patch.

And it'll take more than several years for the committee to agree on it.

With the current solution the change can be done NOW, without any performance or usage impact. With lots of actual bugfixes.

Cook: security things in Linux v5.1

Posted Jun 11, 2019 19:23 UTC (Tue) by nix (subscriber, #2304) [Link]

Also, the new keyword rweikusat2 wants so badly that he's willing to wait literally years for it is... already present as a GCC language extension, as ten seconds of reading the GCC documentation makes clear. It's weirdly spelled ("__attribute__((fallthrough))'), but it is there. So you don't have to use a magic comment if you don't want to.

It's not as if rweikusat's solution is a solution in any case: as you note, using any switch statement replacement would require going through all of them and changing them, inspecting every case to see if it needs to be fallthrough or not. This is exactly the same as what is being done now, except with years of added pointless delay in which actual bugs go disregarded. The perfect really *is* the enemy of the good in this case.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 19:42 UTC (Tue) by tao (subscriber, #17563) [Link]

"Instead, it 'uncovered' that the vast majority of of switch cases without break were correct."

In other words, it 'uncovered' that there were indeed switch cases without break that weren't correct, and that would've gone unnoticed
otherwise, and that there was a non-zero chance of more such bugs being merged as time goes by.

This patch set, when all annotations are in place, will allow all fall-throughs without such comments to be treated as errors, thus eliminating a whole class of bugs. I'd say that's pretty nice for the oh so big inconvenience for flawless programmers such as yourself that have to go through the extreme extra job of making every fall-through explicit.

Cook: security things in Linux v5.1

Posted Jun 4, 2019 19:43 UTC (Tue) by bnorris (subscriber, #92090) [Link]

> What "most" are you looking at?

Ah, so I see there were multiple links:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

The first shows all the noisy patches that don't fix real bugs, where the latter showed true bugfixes. It's possible there was a miscommunication in the OP to which I originally replied. (It's also possible the blog has been updated in the meantime.) As I see it, the "missing break" link was not misleading: it lists a moderate number of real bugfixes.

But indeed, there were many more patches to silence the warnings than there were patches to fix bugs. Such is life when cleaning up the edges of a language like C.