Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Jun 2018 18:56:13 +0000
From: "Edgecombe, Rick P" <>
To: "" <>
CC: "" <>, "Van De
 Ven, Arjan" <>, ""
	<>, "" <>,
	"" <>, "Accardi, Kristen C"
	<>, "" <>,
	"" <>, ""
	<>, "Hansen, Dave" <>
Subject: Re: [PATCH 0/3] KASLR feature to randomize each loadable module

On Wed, 2018-06-20 at 15:33 -0700, Kees Cook wrote:
> > The new __vmalloc_node_try_addr function uses the existing function
> > __vmalloc_node_range, in order to introduce this algorithm with the
> > least
> > invasive change. The side effect is that each time there is a
> > collision when
> > trying to allocate in the random area a TLB flush will be
> > triggered. There is
> > a more complex, more efficient implementation that can be used
> > instead if
> > there is interest in improving performance.
> The only time when module loading speed is noticeable, I would think,
> would be boot time. Have you done any boot time delta analysis? I
> wouldn't expect it to change hardly at all, but it's probably a good
> idea to actually test it. :)

Thanks, I'll do some tests.

> Also: can this be generalized for use on other KASLRed architectures?
> For example, I know the arm64 module randomization is pretty similar
> to x86.

I started in the x86/kernel/module.c because that was where the
existing implementation was, but I don't know of any reason why
itĀ could not apply to other architectures in general.

The randomness estimates would be different if module size probability
distribution, module space size or module alignment are different.

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.