[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Oct 2016 12:59:37 -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>,
Thomas Garnier <thgarnie@...gle.com>
Subject: Re: initcall randomization
On Tue, Oct 11, 2016 at 11:28 AM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 10 October 2016 at 23:17, Kees Cook <keescook@...omium.org> wrote:
>> 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?
>>
>
> It typically looks like
>
> modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
> vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
> .text : 0xffff0d61922a0000 - 0xffff0d6192a80000 ( 8064 KB)
> .rodata : 0xffff0d6192a80000 - 0xffff0d6192dd0000 ( 3392 KB)
> .init : 0xffff0d6192dd0000 - 0xffff0d6193020000 ( 2368 KB)
> .data : 0xffff0d6193020000 - 0xffff0d61930d3200 ( 717 KB)
> .bss : 0xffff0d61930d3200 - 0xffff0d6193116d2c ( 271 KB)
> fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
> PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
> vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
> 0xffff7ebfb4000000 - 0xffff7ebfb7ff0000 ( 63 MB actual)
> memory : 0xffffafed00000000 - 0xffffafedffc00000 ( 4092 MB)
>
> So the kernel virtual mapping is covered by the vmalloc area (and will
> be randomized to somewhere in the first half of that range when kaslr
> is in effect). The module area is listed separately, but that range is
> only used when kaslr is off. If kaslr is on, the 128 MB module region
> will be placed randomly in the first half of the vmalloc region as
> well, and depending on CONFIG_RANDOMIZE_MODULE_REGION_FULL, it will
> intersect the kernel mapping (to allow relative branches without PLT
> entries), or be randomized completely independently.
>
> vmalloc and ioremap calls will simply be served bottom up, which is
> why the beginning of the vmalloc area mostly looks the same between
> boots, i.e., all non-kaslr boots look identical, and all kaslr boots
> look identical with little variation.
>
> I am aware that random vmalloc is a bad idea, hence my suggestion to
> perhaps randomize during the __init phase. I must admit that this is
> simply me holding the randomization hammer and looking for things that
> vaguely resemble nails, hence my request for discussion rather than
> proposing patches.
Ah-ha, thanks for the details here. And the KASLR offset will push all
of these around, then? Would it be possible to separately randomize
the base of vmalloc and vmemmap?
-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.
