In brief

get_random_int() for address space layout randomization was examined on last week's Security page, but, since then, some additional ideas have been discussed. Performance was the main reason to stick with the partial MD4 hash that is in the current code, but other possibilities are being considered. Eric Biederman noted that using a stream cipher such as AES might produce high-quality randomness without the performance penalty, but Matt Mackall didn't agree: "It's also unclear that encrypting small blocks with software AES is actually a performance win relative to SHA1, once you look at the key scheduling overhead and the cache footprint of its s-boxes."

Willy Tarreau pointed out that hash functions used to produce the random numbers actually generate far more data than is currently used. Storing the output of half_md4_transform() (or that of a different implementation using the much stronger SHA1 hash) and returning 4-byte chunks from the full—128 or 160 bit—hash value for each call would perform much better. But, Linus Torvalds is concerned that giving out more of the hash value could lead to easier attacks: "I personally suspect that it would be _much_ easier to attack the hash if we actually gave out the whole 16 bytes (over several iteration), when compared to what we do now (only give out a small part and then re-hash)." No patches emerged from the discussion, but no one is completely happy with the current implementation, so that could change at some point.

OOM by any other name. The out-of-memory (OOM) killer has often been featured on this page. But Christoph Lameter raised a previously unseen complaint about OOM in a recent discussion:

Christoph says that users are tempted to add more memory in response to OOM situations, while the real fix is often to be found elsewhere - fixing the application which is locking down the bulk of RAM, for example. There was some discussion of changing the OOM messages to read something like "Unable to satisfy memory allocation request and not making progress reclaiming from other sources," but nothing has been merged at this point.

Tracepoints leave a trace: one of the key design criteria for kernel tracepoints is that their impact must be minimal when they are not being used. So Jason Baron was surprised to find out that, with the current tracepoint implementation, arguments to tracepoints are being evaluated before the determination of whether the tracepoint is active. In response, he prepared a patch to prevent the evaluation of arguments for inactive tracepoints. The patch works, but at a cost: it requires a change to the internal tracepoint API.

There is resistance to the API change, mostly because the people involved seem to think that the new version is uglier and that the problem is really a bug in GCC. It may prove hard to avoid, though; even if GCC is fixed soon, older versions will be out there for a long time. Minimizing overhead is seen as more important than API beauty, so, unless somebody comes up with a clever workaround, there may be no avoiding an unwanted tracepoint change.

Union mounts: there is a new set of union mount patches out there for evaluation, along with the necessary user-space tools. Valerie Aurora has put together a howto page for those who would like to experiment with this code. See this LWN article (also by Valerie) for information on the implementation of union mounts.