[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161005194354.GA26546@remoulade>
Date: Wed, 5 Oct 2016 20:43:55 +0100
From: Mark Rutland <mark.rutland@....com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: kernel-hardening@...ts.openwall.com, Kees Cook <keescook@...omium.org>,
Laura Abbott <labbott@...oraproject.org>
Subject: Re: initcall randomization
Hi Ard,
On Wed, Oct 05, 2016 at 06:09:01PM +0100, Ard Biesheuvel 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)
As a stress-testing/debugging feature, this would certainly be useful.
>From a hardening PoV, I can't immediately see what this would gain us.
Also, if we ever solve probe dependencies, I suspect that will remove a lot of
scope for re-ordering.
> Since boot time mappings are often performed in initcalls, this could
> potentially reduce the predictability of the layout of the virtual
> kernel space.
Given you say 'mappings', I assume you mean {io,mem}remap() and friends. If we
have the entropy to randomize the initcalls, can't we use that to randomize the
VAs of those mappings? Or is this for the early allocators where that is
trickier?
For general allocations there's the freelist randomization, though I believe
that the order is predictable at boot time, per the commit message for
210e7a43fa905bcc ("mm: SLUB freelist randomization").
Thanks,
Mark.
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.
