diff -u: What's New in Kernel Development
There's an ongoing impulse among a diversity of developers to be able to compile some or all of the Linux kernel as a library, so that a piece of software could use kernel services and APIs while running under a different kernel entirely, or a different operating system.
This time, the impulse came from Octavian Purdila, creator of the Linux Kernel Library (LKL), essentially an entire kernel compiled as a static library. He distinguished LKL from projects like User Mode Linux (UML), saying that LKL was more lightweight, having no infrastructure requirements or needing any particular sort of runtime environment.
A bunch of folks expressed interest, especially in terms of interacting with similar projects like libOS and libguestFS. And, Richard Weinberger remarked that LKL seemed to solve UML's biggest pain points: the need to use ptrace() to handle system calls and to do virtual memory management using SIGSEGV.
In a device-centric world with heavy, inefficient battery technology, there's a big incentive to figure out ways to save power. One possibility is to turn off portions of hardware when they're currently not in use, like a phone's touchscreen when the phone is in your pocket.
The difficulty lies in knowing exactly which piece of hardware to turn off, and when. If there's a clear user action, like flipping closed a flip-phone, the problem is simplified. Irina Tirdea recently tried to recognize such actions and come up with mechanisms to respond to them properly. She posted some patches to do this.
Octavian Purdila, also working on the project with Irina, described a target scenario as being when a touchscreen has been blanked but is still aware of the user's touch—through the fabric of a pocket, for example. The goal of the patches, he said, would be to save power by turning off all the hardware associated with that screen, and turn everything on again when the user activates the device.
The problem with this sort of feature is that it could be implemented along any of a number of different layers of the kernel code. The ideal location could make the difference between a complex, easily broken implementation and a simple, efficient implementation. Several folks felt that Irina and Octavian's approach was in the wrong part of the kernel, and the discussion devolved into a consideration of completely different approaches.
No consensus arose, although the allure of power-savings will undoubtedly keep the debate alive.
Mounting a filesystem under a virtual machine can be tricky. Security privileges and restrictions need to be respected, or else a filesystem could become a vector of attack by a malicious user. This particular area of kernel development also tends to have a wide appeal among companies trying to support their products, so it's possible for a variety of developers to find themselves working at cross purposes and need to accommodate each other before their patches can be accepted.
Seth Forshee and Eric Biederman, for example, recently wrote some patches to allow mounting Ext4 and FUSE filesystems by unprivileged users, ignoring the security information that otherwise might prevent those users from accessing that data.
Meanwhile, Lukasz Pawelczyk was working on code specifically to support that same security information.
A debate sprang up over the particular context involved. Andy Lutomirski suggested that if a filesystem contained a user's own data, it would be fine to override security features, on the grounds that users should be able to do what they wanted with their own data. While Casey Schaufler replied that the kernel shouldn't care what the user knew about the data, it had to follow the security protocols or else it wouldn't be able to enforce them at all.
On the other hand, as Eric pointed out, filesystems like FAT and Minix weren't capable of storing the same type of security information as more modern filesystems. There had to be a way, he said, to mount such filesystems without requiring them to support security features they couldn't support.
It's an ongoing debate. Security trumps all other considerations, including dire need, so an issue like unprivileged filesystem mounts inevitably will involve a consideration of the specific context in which a user might try to do something. Often there's some kind of crazy nuance that makes something feasible when you could have sworn it never would be feasible.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Nativ Disc
- The Many Paths to a Solution
- Recovery of RAID and LVM2 Volumes
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Naztech's Roadstar 5 Car Charger
- Securing the Programmer
- Synopsys' Coverity
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Glass Padding
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide