[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Oct 2016 13:30:48 -0700
From: Kees Cook <keescook@...omium.org>
To: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Cc: Laura Abbott <labbott@...oraproject.org>, Mark Rutland <mark.rutland@....com>
Subject: Re: initcall randomization
On Wed, Oct 5, 2016 at 10:09 AM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> Did anyone ever look into whether there is anything to gain in terms
> of hardening from randomizing the order initcalls are issued at each
> level? I know entropy is hard to come by at this stage, but on recent
> UEFI systems, this is something we could potentially solve
> generically. (It may uncover some breakage as well, but only hidden
> breakage that could already surface at any time due to linker changes,
> so I think this could serve as a diagnostic option as well)
It could be a nice addition to CONFIG_RANDOMIZE_MEMORY which already
tries to address the "predictable memory locations at every boot"
problem by randomizing the offset of the kernel memory mappings on
x86_64. Could this be done on arm64 too?
> Since boot time mappings are often performed in initcalls, this could
> potentially reduce the predictability of the layout of the virtual
> kernel space. But before I start experimenting with this, I thought
> I'd ask if anyone has ever looked into this.
As Greg mentioned, I bet there are some implicit ordering (and
explicit) that would need solving.
-Kees
--
Kees Cook
Nexus Security
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.
