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:
While we are at it: Could we get rid of the name "Out of Memory"
and stop printing texts to that effect? What we call an OOM is a
failure to perform memory reclaim or we are running out of reserves
due to not being able to run reclaim. Mostly this is due to OS
internal issues having nothing to do actual amounts of memory
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.
to post comments)