Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Oct 2016 15:17:30 -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 2:45 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 5 October 2016 at 13:30, Kees Cook <keescook@...omium.org> wrote:
>> 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?
>>
>
> The arm64 implementation of KASLR randomizes the placement of
> installed memory inside the linear mapping. If this is the same thing,
> it seems this should be configurable under CONFIG_RANDOMIZE_MEMORY
> instead?
>
> But indeed, as Mark points out, this would primarily affect the
> vmalloc space, and would be defeated by dependency based init (if that
> ever materialises), and so it might make more sense to target __init
> stage vmalloc/ioremap invocations specifically.

I've almost got my HiKey running a modern kernel so I can answer with
some level of certainty, but looking at an older kernel's memory
layout, it seemed like arm64 has two primary memory areas, "kernel"
and "everything else". Did I understand that correctly, and/or is it
still true?

Is the vmalloc area offset from the kernel text, or does it have its
own static location in kernel virtual memory?

-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.