linux-hardening - Re: [PATCH v3] mm/vmalloc: randomize vmalloc() allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <124b32de-2422-615c-90fe-ca5a6d64d179@gmail.com>
Date:   Sat, 6 Mar 2021 07:57:15 +0200
From:   Topi Miettinen <toiwoton@...il.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-hardening@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
        Jann Horn <jannh@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Linux API <linux-api@...r.kernel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Mike Rapoport <rppt@...nel.org>, Vlad Rezki <urezki@...il.com>,
        Cristiano Giuffrida <c.giuffrida@...nl>
Subject: Re: [PATCH v3] mm/vmalloc: randomize vmalloc() allocations

On 6.3.2021 3.13, Andrew Morton wrote:
> On Mon, 15 Feb 2021 22:26:34 +0200 Topi Miettinen <toiwoton@...il.com> wrote:
> 
>> Memory mappings inside kernel allocated with vmalloc() are in
>> predictable order and packed tightly toward the low addresses, except
>> for per-cpu areas which start from top of the vmalloc area. With
>> new kernel boot parameter 'randomize_vmalloc=1', the entire area is
>> used randomly to make the allocations less predictable and harder to
>> guess for attackers. Also module and BPF code locations get randomized
>> (within their dedicated and rather small area though) and if
>> CONFIG_VMAP_STACK is enabled, also kernel thread stack locations.
>>
>> On 32 bit systems this may cause problems due to increased VM
>> fragmentation if the address space gets crowded.
>>
>> On all systems, it will reduce performance and increase memory and
>> cache usage due to less efficient use of page tables and inability to
>> merge adjacent VMAs with compatible attributes. On x86_64 with 5 level
>> page tables, in the worst case, additional page table entries of up to
>> 4 pages are created for each mapping, so with small mappings there's
>> considerable penalty.
>>
>> ...
>>
> 
> How useful is this expected to be?  What sort of attack scenarios will
> this help to defend against?

Since there's a clear trade-off between best performance and additional 
address space randomization, this will not be useful for those who 
prefer performance. That's also why this is not the default but has to 
be enabled with a boot parameter.

For those who are willing to pay the price for additional hardening, the 
purpose is to make attacks against KASLR (similar to TagBleed [1]) more 
difficult since the targeted memory locations may reside anywhere in the 
32 TB vmalloc region and knowing one address does not reveal the others.

[1] https://download.vusec.net/papers/tagbleed_eurosp20.pdf

-Topi