On 15.3.2021 19.47, Uladzislau Rezki wrote:
On Mon, Mar 15, 2021 at 09:16:26AM -0700, Kees Cook wrote:
On Mon, Mar 15, 2021 at 01:24:10PM +0100, Uladzislau Rezki wrote:
On Mon, Mar 15, 2021 at 11:04:42AM +0200, Topi Miettinen wrote:
What's the problem with that? It seems to me that nothing relies on specific
addresses of the chunks, so it should be possible to randomize these too.
Also the alignment is honored.
My concern are:
- it is not a vmalloc allocator;
- per-cpu allocator allocates chunks, thus it might be it happens only once. It does not allocate it often;
That's actually the reason to randomize it: if it always ends up in the
same place at every boot, it becomes a stable target for attackers.
Probably we can randomize a base address only once when pcpu-allocator
allocates a fist chunk during the boot.
- changing it will likely introduce issues you are not aware of;
- it is not supposed to be interacting with vmalloc allocator. Read the
comment under pcpu_get_vm_areas();
Therefore i propose just not touch it.
How about splitting it from this patch instead? Then it can get separate
testing, etc.
It should be split as well as tested.
Would you prefer another kernel option `randomize_percpu_allocator=1`,
or would it be OK to make it a flag in `randomize_vmalloc`, like
`randomize_vmalloc=3`? Maybe the latter would not be compatible with
static branches.
-Topi
--
Vlad Rezki
