linux-hardening - Re: [PATCH] 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 PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

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

Date:   Fri, 4 Dec 2020 18:53:47 +0200
From:   Topi Miettinen <toiwoton@...il.com>
To:     David Laight <David.Laight@...LAB.COM>,
        'Mike Rapoport' <rppt@...nel.org>
Cc:     "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.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>
Subject: Re: [PATCH] mm/vmalloc: randomize vmalloc() allocations

On 4.12.2020 15.33, David Laight wrote:
> From: Topi Miettinen
>> Sent: 04 December 2020 10:58
>>
>> On 4.12.2020 1.15, David Laight wrote:
>>> From: Mike Rapoport
>>>> Sent: 03 December 2020 06:58
>>>>
>>>> On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
>>>>> On 1.12.2020 23.45, Topi Miettinen wrote:
>>>>>> Memory mappings inside kernel allocated with vmalloc() are in
>>>>>> predictable order and packed tightly toward the low addresses. 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.
>>>
>>> Isn't that going to horribly fragment the available address space
>>> and make even moderate sized allocation requests fail (or sleep).
>>
>> For 32 bit architecture this is a real issue, but I don't think for 64
>> bits it will be a problem. You can't fragment the virtual memory space
>> for small allocations because the resulting page tables will not fit in
>> RAM for existing or near future systems.
> 
> Hmmm truly random allocations are going to need 3 or 4 extra page tables
> on 64bit systems. A bit overhead for 4k allocates.
> While you won't run out of address space, you will run out of memory.

There are 3500 entries in /proc/vmallocinfo on my system with lots of 
BPF filters (which allocate 8kB blocks). The total memory used is 740MB. 
Assuming that every entry needed additional 4 pages, it would mean 55MB, 
or 7.4% extra. I don't think that's a problem and even if it would be in 
some case, there's still the option of not using randomize_vmalloc.

-Topi