Linus Torvalds reported on some GCC compiler warnings that he felt were unnecessary, and he gave his opinion on how they should work instead. Specifically, GCC 5.1 would issue a warning against using a switch statement with a boolean variable, presumably because a boolean would be better handled by a simple if statement.

Linus posted the following counter-example:

switch (a) {
case 1:
    A;
    if (b)
         break;
    B;
    /* fallthrough */
case 2:
    C;
}

And he said:

You share that C case for some conditions but not others.

You can do the same using goto, of course, but you can not do it with pure nested if () statements.

So even with just two cases, switch () is syntactically more powerful than if (), because it allows more structured exits.

Linus said that a more appropriate warning from GCC would be when the data type of the switch variable was different from the data type of the case variable. In that case, he said, a warning would make perfect sense. But warning against using a boolean variable in a switch at all, he felt, was going overboard. He said that:

switch (boolean) {
case true:

made far more sense than following the recommendation in the GCC documentation of casting to an integer:

switch ((int)boolean) {
switch 1:

He said anyone who preferred the latter over the former "clearly has absolutely zero taste and is just objectively wrong".

Tadeusz Struk has proposed some patches to implement a new public key encryption API. The idea is to have software routines in place when no encryption hardware is available, but to offload the work to hardware when possible. In general though, any module could provide its own RSA and DSA implementation.

It's not entirely a new concept—the kernel already supported public key encryption for verifying digitally signed driver modules. But, Tadeusz's code is intended to replace the old crypto code. Along with his patches implementing the feature, Tadeusz submitted patches migrating older usages to the new service.

There were some technical suggestions and some minor objections, but ultimately, it does seem as though the old crypto code will be replaced by Tadeusz's new stuff. The biggest problem seemed to be how to make it easy for user code to handle drivers that implemented only a partial subset of the RSA and DSA API. Initially, Tadeusz planned to allow drivers simply to encode a list of the features they provided, but Herbert Xu convinced him to require drivers to implement at least a complete minimal subset of features, so users could rely on them without doing lots of tests.

Filesystem capabilities still have not come into their own. Originally intended as a way to loosen targeted security constraints on user processes without going all the way to the extreme of running as root, the poor initial design of capabilities has sometimes led to more security problems than it solved.

One problem has been capability inheritance—the ability of one process to pass along its same set of capabilities to processes it invokes. This is the equivalent of user processes running sub-processes as that user, or root processes running sub-processes as root—something UNIX always has supported. But capabilities haven't implemented that feature properly, and the available workarounds have tended to make it easier for hostile users to gain root privileges on a system.

Recently Andy Lutomirski, working off ideas by Christoph Lameter and Serge Hallyn, produced some patches that re-envisioned capability inheritance in a way that, without breaking current usage, they claimed would provide a saner and more secure form of inheritance.

Capabilities work by identifying secure abilities that are available to a given process. A process has a certain set of capabilities, which can then be masked off, leaving only the ones that actually will be needed by that process. One of these masks is the "inheritable" mask, called pI. The pI mask is supposed to control which capabilities are inheritable by sub-processes. The problem is that it doesn't do that properly, although changing its behavior could break existing user code.

Andy's code got around this dilemma by introducing a new pA mask, which he said would do what pI should have done originally. The pA mask, Andy said, would introduce new logic and some nuanced behaviors to allow a predictable form of inheritance that would avoid the security exploits that had been plaguing users.

Several folks pointed out, and Andy acknowledged, that this wasn't a perfect solution and left certain problems unsolved. But the bottom line, he said, was that his code represented a real improvement and better overall direction in a situation where no one else was able to offer any alternatives beyond the status quo.