Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Jan 2018 13:15:08 -0800
From: Matthew Wilcox <>
To:, Dave Chinner <>,
	Christopher Lameter <>, Kees Cook <>
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).


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.