Rusty recently committed my patch to convert lguest over to the modern hrtimers API. This allows guests to run tickless (also known as dynamic ticks), which means that instead of being fed a constant stream of timer ticks, a guest will only receive a timer interrupt when it really needs one. As a bonus, these ticks will likely arrive with a much higher resolution than every 1/1000 s (or whatever HZ was set to).

Tickless operation is important for virtualized systems. Imagine if you had ten guests, each running at 1000HZ. With static ticks, the host would need to generate 10,000 virtual ticks per second, and each guest would be handling 1000 synthetic hardware interrupts/s, the vast majority of which would very likely be unnecessary. Instead, lguest now allows guests to request clock ticks to occur only at some appropriate point in the future, with nanosecond resolution.

A virtual clock event device is instantiated for each running guest. Instead of being a programmable piece of hardware (such as an HPET), the virtual device is quite simply a high-resolution timer attached to the guest. When the guest needs to program a clock tick event, the smarts of which are thankfully buried in the hrtimer code, it issues a new hypercall, HCALL_SET_CLOCKEVENT, with an argument in nanoseconds representing the relative amount of time until the event is required. The hypercall traps into the host, which converts the relative delta into an absolute value (we know when ‘now’ is in the guest’s virtual time, as we’re in its hypercall context, which is similar to being in the syscall context of a userland application), then starts a highres timer running in the host. When this fires, the host simply sets the timer interrupt for the guest. When the guest runs next, its own hrtimer mechanism is then invoked to process the timer interrupt.

Conceptually, it’s quite simple, which keeps the puppies happy. This is due in large part to the great hrtimer subsystem by Thomas Gleixner and Ingo Molnar. Check out the 2006 OLS paper for more info on hrtimers, as well as the LWN articles here and here.

Josh Brindle has written an in-depth article, Secure Networking with SELinux, which covers some of the different network security mechanisms in SELinux. Of particular value is its discssion of labeled IPSec, which is currently not well documented. Josh includes some worked examples of use with explanations, and discussion of potential uses:

For example, one possible application of this technology is to have an ‘internal’ and ‘external’ browser on employee workstations. The internal browser would run in a domain that is allowed to access internal company web application servers that contain confidential customer information while the external browser can access the internet. This reduces the risk that rogue internet content can compromise your internal data. This kind of separation would be much more difficult (or impossible) without SELinux’ advanced networking controls.

Linux now has some very powerful and expressive network security capabilities; perhaps unmatched anywhere. Better usability is an important next step with this, and I suspect from comments in the article that Josh may have more for us on this soon.

Dan Walsh writes in detail about how SELinux mitigates recent vulnerabilities in Samba. The referenced vulnerabilities potentially allow remote arbitrary code execution due to coding errors: exactly the kind of thing SELinux was designed to protect against.

It’s notable is that the SELinux memory execution controls are key here, as they are often the cause of problems with third-party software installation vs. SELinux issues. More often than you’d expect, applications and/or libraries will try to do highly questionable things like making areas of the heap executable, which SELinux will typically prevent. This tends to be seen more in closed software, which is also unfortunately harder to fix. In any case, SELinux is usually doing the right thing for you when this happens, as explained by Ulrich Drepper.

Generally, the best solution for software such as this is to fix it and make it safe; not to disable security protections. Ulrich provides example code of how to make such fixes in the referenced article.

SELinux kernel developers and other curious folk may be interested in the new SELinux Kernel Development Wiki page.

This is where we’ll maintain the current todo list and maintain various resources relating to SELinux kernel development. Anyone active in this area as a developer is welcome to edit the page. Accounts may be requested via Karl MacMillan.