[kernel-hardening] initcall randomization

[kernel-hardening] initcall randomization

[Ard Biesheuvel]

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)

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.

Regards,
Ard.

[kernel-hardening] Re: initcall randomization

[Mark Rutland]

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.

Re: [kernel-hardening] initcall randomization

[Greg KH]

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)

We rely on link-order init call dependancy in the kernel a lot, so be
very careful about reording them.

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

I think you will break things, try it yourself and see :)

good luck!

greg k-h

Re: [kernel-hardening] initcall randomization

[Kees Cook]

On Wed, Oct 5, 2016 at 10:09 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.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

Re: [kernel-hardening] initcall randomization

[Ard Biesheuvel]

On 5 October 2016 at 13:30, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Oct 5, 2016 at 10:09 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.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.

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

I guess we should expect some things to break if initcalls within the
same levels are reordered. The question is if we should treat those as
defects. I understand that we can currently rely on GNU ld not to
reorder section contents, even with the multiple levels of partial
linking that we do in the kernel, but this is not documented afaik,
and not guaranteed. Things like LTO may break some assumptions here,
if anyone ever attempts that.

But given the feedback, it seems to make more sense to randomise
boottime vmalloc/ioremap calls directly, so I will experiment with
that first.

-- 
Ard.

Re: [kernel-hardening] initcall randomization

[Kees Cook]

On Wed, Oct 5, 2016 at 2:45 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 5 October 2016 at 13:30, Kees Cook <keescook@chromium.org> wrote:
>> On Wed, Oct 5, 2016 at 10:09 AM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.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

Re: [kernel-hardening] initcall randomization

[Ard Biesheuvel]

On 10 October 2016 at 23:17, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Oct 5, 2016 at 2:45 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 5 October 2016 at 13:30, Kees Cook <keescook@chromium.org> wrote:
>>> On Wed, Oct 5, 2016 at 10:09 AM, Ard Biesheuvel
>>> <ard.biesheuvel@linaro.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.

Re: [kernel-hardening] initcall randomization

[Kees Cook]

On Tue, Oct 11, 2016 at 11:28 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 10 October 2016 at 23:17, Kees Cook <keescook@chromium.org> wrote:
>> On Wed, Oct 5, 2016 at 2:45 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> On 5 October 2016 at 13:30, Kees Cook <keescook@chromium.org> wrote:
>>>> On Wed, Oct 5, 2016 at 10:09 AM, Ard Biesheuvel
>>>> <ard.biesheuvel@linaro.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

Re: [kernel-hardening] initcall randomization

[Ard Biesheuvel]

On 11 October 2016 at 20:59, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Oct 11, 2016 at 11:28 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 10 October 2016 at 23:17, Kees Cook <keescook@chromium.org> wrote:
>>> On Wed, Oct 5, 2016 at 2:45 PM, Ard Biesheuvel
>>> <ard.biesheuvel@linaro.org> wrote:
>>>> On 5 October 2016 at 13:30, Kees Cook <keescook@chromium.org> wrote:
>>>>> On Wed, Oct 5, 2016 at 10:09 AM, Ard Biesheuvel
>>>>> <ard.biesheuvel@linaro.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?
>

When KASLR is in effect:
- the text/rodata/init/data/bss regions are kept together and moved
around inside the vmalloc area
- the fixed 'modules' region will not be used, and another randomly
placed 128 MB region inside the vmalloc region will be used
- the 'memory' region will be randomized, and by association, the
vmemmap 'actual' region
- the 'fixed' and 'PCI I/O' regions always stay in the same place

Randomizing the base of vmemmap independently would result in
page_address()/virt_to_page() translations that are no longer strictly
based on build time constants, and so I would prefer to avoid that
(and vmemmap is already randomized along with the 'memory' region)
As for the vmalloc region, I guess it would be possible to simply
start the bottom up allocations at a random offset into the region
rather than at the base.

Re: [kernel-hardening] initcall randomization

[Mark Rutland]

On Tue, Oct 11, 2016 at 07:28:46PM +0100, Ard Biesheuvel wrote:
> 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,

I must confess ignorance here; what problems does random vmalloc pose in
particular?

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

Do we have a particular threat model this helps with?

Is it similar to that for SLUB freelist randomization?

Do we have vmalloc area sepcific information leaks?

Thanks,
Mark.

Re: [kernel-hardening] initcall randomization

[Ard Biesheuvel]

(+ Nick)

On 12 October 2016 at 00:40, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Oct 11, 2016 at 07:28:46PM +0100, Ard Biesheuvel wrote:
>> 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,
>
> I must confess ignorance here; what problems does random vmalloc pose in
> particular?
>

It has been attempted in Android, and resulted in vmalloc failures due
to fragmentation. I realize this may not apply to 64-bit ARM, though
(and I assume the Android example concerned 32-bit ARM)

>> 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.
>
> Do we have a particular threat model this helps with?
>
> Is it similar to that for SLUB freelist randomization?
>
> Do we have vmalloc area sepcific information leaks?
>

Well, that was my question as well. Given that it seemed like a good
idea for the Android guys at the time, I would assume yes

Nick?

Re: [kernel-hardening] initcall randomization

[Kees Cook]

On Wed, Oct 12, 2016 at 1:55 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> (+ Nick)
>
> On 12 October 2016 at 00:40, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Tue, Oct 11, 2016 at 07:28:46PM +0100, Ard Biesheuvel wrote:
>>> 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,
>>
>> I must confess ignorance here; what problems does random vmalloc pose in
>> particular?
>>
>
> It has been attempted in Android, and resulted in vmalloc failures due
> to fragmentation. I realize this may not apply to 64-bit ARM, though
> (and I assume the Android example concerned 32-bit ARM)
>
>>> 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.
>>
>> Do we have a particular threat model this helps with?
>>
>> Is it similar to that for SLUB freelist randomization?
>>
>> Do we have vmalloc area sepcific information leaks?
>>
>
> Well, that was my question as well. Given that it seemed like a good
> idea for the Android guys at the time, I would assume yes
>
> Nick?

The specific issue is to randomize any targets living in vmalloc areas
that are allocated at boot time, which results in effectively static
locations for a given software/hardware combination. Thomas
(explicitly CCed now) saw a bunch of these when he was looking for
possible targets, which motivated his RANDOMIZE_MEMORY config for x86.
He also randomized the base offset for page tables, which are another
very common target, though it sounds to me like those would already be
randomized with the kernel position?

-Kees

-- 
Kees Cook
Nexus Security