[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Jan 2018 13:15:08 -0800
From: Matthew Wilcox <willy@...radead.org>
To: kernel-hardening@...ts.openwall.com, Dave Chinner <dchinner@...hat.com>,
Christopher Lameter <cl@...ux.com>, Kees Cook <keescook@...gle.com>
Subject: Write-once memory
At the kernel hardening BOF yesterday, we came up with the concept of
write-once memory.
The problem it's intended to solve is that XFS allocates a large amount
of memory at filesystem mount time which is conceptually read-only until
it's destroyed. Protecting this by making the pages read-only would be
a nice hardening improvement (both for security and as a defense against
stray writes).
At the moment that data is mixed in with read-write data, so XFS will need
modifying to use this new facility.
We believe that the right way to support write-once memory is through
slab APIs. Something like:
void kmem_cache_init_once(struct kmem_cache *s, void (*init)(void *),
void *data);
used like this:
const struct my_ro_data *alloc_my_ro_data(struct my_context *context, gfp_t gfp)
{
const struct my_ro_data *p = kmem_cache_alloc(cache, gfp);
kmem_cache_init_once(p, my_init_once, context);
return p;
}
The implementation would change the page protection on that slab page
from RO to RW temporarily while my_init_once() is running. This would
lead to a short window of vulnerability, but that doesn't feel like
an unreasonable tradeoff for memory efficiency (being able to allocate
multiple my_ro_data per page).
Feedback?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
