Zack's Kernel News

Status of "make menuconfig"

Aldo Iljazi suggested that since make nconfig was added to the kernel in 2.6.35, make menuconfig has become redundant and should be removed. Both build targets are used to configure the kernel before compiling, but make nconfig is a fork of make menuconfig that tries to have a sleeker, more modern-looking appearance.

The suggestion met a lot of resistance. Alexander Holler said that nconfig seemed to rely on the Fn keys to control the configuration process, which would cause problems on keyboards that had no Fn keys. He pointed out that not only some physical keyboards, but also software keyboards on "smart" phones, had no Fn keys. This would make it difficult to ssh into a workstation from a phone to compile the kernel with nconfig.

Randy Dunlap eliminated that objection when he pointed out that nconfig could use either the Fn keys or the equivalent number keys, which did exist in software keyboards. But, Randy said he still saw no need to get rid of menuconfig.

Richard Weinberger also added that very few people currently used nconfig, whereas menuconfig had an enormous user base. He saw "zero reason to drop menuconfig." And, Alexander said he preferred the menuconfig interface, because he could simply Tab through available menu options, which felt more intuitive to him than using the Fn keys or number keys.

Several other people stood up for menuconfig, and eventually Aldo backed off of his proposal.

It's interesting to compare the sort of redundancies that are easily taken out of the kernel with the sort that people fight to keep. In this case, nconfig may be better maintained and even just better in general than menuconfig, but menuconfig has so many users that the fact that it's become redundant makes no real difference.

On the other hand, one might argue that nconfig was redundant even before it was accepted into the source tree, but it still made it in. And, during the recent debate no one suggested that it be removed, even though it had very few users.

My guess is that these sorts of features just have a much lower bar to entry than patches that might affect the speed of the running kernel or the amount of memory used. A new make target, or even a new build system, can go into the source tree without much fuss  – just to see how well it does and whether it attracts a bunch of maintainers and contributors.

Switching User Creds

Jim Lieb implemented a new switch_creds() system call intended to allow file servers to perform write operations with the credentials of their client user. Otherwise, things like quotas and access controls wouldn't be able to tell whether or not a given operation was allowed.

Linux currently handles this situation piecemeal, with a combination of setfsuid(), setfsgid(), setgroups(), and other calls, to wrangle the needed permissions into place. Jim's idea would simplify the whole process and would use the read-copy update subsystem more efficiently by doing certain operations only once instead of having to repeat them.

Al Viro took a look at Jim's implementation but didn't like it – or, at least, he felt that it used some unnecessary magic files and complex data structures. The whole logic, he thought, could be dramatically simplified, and he posted a reimplemented function to do that.

Eric W. Biederman pointed out that Al's idea also needed appropriate CAP* capabilities. Jim saw the wisdom of Al's approach and started to rework his code to use the new design.

Eric also mentioned that the code should probably check to make sure the new identity didn't accidentally gain any capabilities it shouldn't have. He posted a long if() statement to do that, but Andy Lutomirski didn't see the value in it. In particular, one of Al's enhancements to Jim's implementation included the idea that any arbitrary file descriptor would satisfy the feature's requirements, and it didn't matter which one was used (Al used /dev/null in his version).

Andy didn't like this at all and felt it was a security risk. He said, "if you're going to pass an fd that grants a capability (in the non-Linux sense of the work), please make sure that the sender actually wants that behavior." He added that he'd "take it as a personal challenge to find at least one exploitable privilege escalation in this."

Eric replied that his first goal was to address the use case that Jim had originally identified, rather than to make the new system call as generically useful as possible.

Regarding Andy's fear of a security problem, Eric said, "If you can't switch to a uid or a gid you couldn't switch to otherwise then the worst that can happen is an information leak. And information leaks are rarely directly exploitable." He added that this particular mechanism for switching user credentials wouldn't give a hostile user any ability they couldn't get using some other means. So, Eric thought the situation was, if not safe, then at least as safe as the status quo.

Meanwhile, Andy posted what he thought was a possible security exploit of Al's and Eric's approach. He said, "Suppose there's a daemon that uses this in conjunction with SCM_RIGHTS. The daemon is effectively root (under the current proposal, it has to be). So a client connects, sends a credential fd, and the daemon impersonates those credentials. Now a malicious user obtains *any* fd opened by root. It sends that fd to the daemon. The daemon then impersonates root. We lose."

At this point, Jim started to get interested again in his original implementation, or at least a closer variant to it. In particular, his original design would only allow reducing the number of capabilities given to the user, not extending them. Reducing the number of capabilities was important, he said, to support quotas and access controls, but there was no reason to risk extending capabilities to a user who shouldn't have them. He added, "in my original patch I pass a user_creds structure that only has the fsuid, fsgid, and altgroups. This means that the caller can *only* impersonate these particular creds for purposes of file access, not priv escalation."

Jim liked Eric's comment about only trying to support the use case that was actually needed. Jim added, "The api I chose allows later extension but only supports what we need now."

Jim and Andy went back and forth a bit on various design issues, and Jim continued to develop his new design and implementation. This time around, he wanted to avoid some of the problems Al had originally mentioned (e.g., untyped multiplexors) but still keep tighter control over the behavior than Al's original recommendation would have.

Eventually, Tetsuo Handa joined the conversation, pointing out a flaw in Jim's new concept. Apparently, there was a brief window of time between several operations in Jim's code, within which a malicious user could gain dangerous privileges.

This put an immediate stop to the discussion, as Jim replied, "I see your point here. If I do a switch_creds and the userland does something like seteuid before I do the revert, we are toast. Correct? This is an issue. Thanks for pointing this out. It is certainly not in my use case but that doesn't mean someone else won't try it. I have some more work to do."

It seems as though, overall, there's support for something along the lines of what Jim wants to do – that is, simplify switching between credentials – but it seems as if there are real security problems to consider, too, on top of which everyone who looks at the project seems to have a different idea of what it should do and how it should be implemented. Clearly, a lot more use cases need to be identified, and the security issues need to be nailed down before anything would go into the source tree.

Trusted Computing Maintainer(s)

Peter Huewe added himself as a TPM (Trusted Platform Module) device driver maintainer, next to several other current TPM maintainers. TPM is a hardware chip that stores system credentials to authenticate the system to other systems that may provide services to it.

Joel Schopp was pleased to see Peter step up as maintainer, and he felt that it would be useful to prune down the list of official maintainers, which included Peter, Leonidas Da Silva Barbosa, Ashley Lai, Rajiv Andrade, Marcel Selhorst, and Sirrix AG. As Joel put it, "I don't think all the listed maintainers are active anymore."

Ashley enthusiastically endorsed Peter joining the maintainer team and praised his work so far. Peter remarked that before taking on the maintainer role, he'd emailed the existing maintainers and heard back from Ashley and Marcel, saying they were actively looking at patches that came in from the community, but that he hadn't heard back from Leonidas, Rajiv, or Sirrix.

Leonidas posted, saying he wasn't doing any more work on TPM and could be removed from the maintainers list.

Rajiv also posted, saying he hadn't been active for a long time and recognized Peter as the project leader at this point. He asked for his name to be removed from the maintainers list, but he offered to help out again if Peter would like. Peter replied that Rajiv could help a lot by reviewing patches as they came in.

On that note, Jason Gunthorpe also remarked that Rajiv's help would be very valuable, saying "there are still lots of patches to go before the subsystem meets the current kernel standard."

Various folks agreed that the maintainer list should be pruned down and that non-responsive maintainers should be removed. It also turned out that Jason had a set of TPM patches waiting to get in, and he submitted them again for review.

Jacob Pan posted patches to implement the TMON tool, to help deal with the increasingly complex issue of heat dissipation on various hardware platforms. He said:

As hardware vendors cope with the thermal constraints on their products, more sensors are added, new cooling capabilities are introduced. The complexity of the thermal relationship can grow exponentially among cooling devices, zones, sensors, and trip points. They can also change dynamically.

To expose such relationship[s] to the userspace, Linux generic thermal layer introduced [a] sysfs entry at /sys/class/thermal with a matrix of symbolic links, trip point bindings, and device instances. To traverse such [a] matrix by hand is not a trivial task. Testing is also difficult in that thermal conditions are often exception cases that [are] hard to reach in normal operations.

Eduardo Valentin was very excited to see this. He said, "I have been using the linaro thermal testing scripts for smoke-testing the systems I am working on," which didn't do the job as well as he'd like. He added that he'd been considering writing a tool similar to TMON himself, and he was happy to see Jacob making his tool available.

The two of them started discussing features and implementation, testing Jacob's code on various platforms, as well as naming. TMON was originally written to do monitoring only, but eventually Jacob expanded the scope to include tuning the various weights and configurations. So, perhaps the "MON" part of the name might become something else.

Most of their conversation focused on actually using the tool and discussing which features could be pushed into the kernel's own logic compared with remaining user-controllable. Ultimately, TMON seems very useful, and the problem space seems quite strange. At one point, Jacob remarked, "if a user wants to know how LCD brightness affect skin temperature, tmon can be used to try it out and see the effectiveness."