linux-kernel - 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 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: <3d20f41c-6c8e-755b-33b4-964b5cc5ac71@gmail.com>
Date:   Fri, 4 Dec 2020 12:58:12 +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 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.

For large allocations (directly mapping entire contents of TB sized NVME 
drives or a special application which needs 1GB huge pages) this could 
be a risk. Maybe this could be solved by reserving some space for them, 
or perhaps in those cases you shouldn't use randomize_vmalloc=1.

The method for reserving the large areas could something like below.

First, consider a simple arrangement of reserving high addresses for 
large allocations and low addresses for smaller allocations. The 
allocator would start searching downwards from high addresses for a free 
large block and upwards from low addresses for small blocks. Also the 
address space would be semi-rigidly divided to priority areas: area 0 
with priority for small allocations, area 1 with equal priority for both 
small and large, and area 2 where small allocations would be placed only 
as a last resort (which probably would never be the case).

The linear way of dividing the allocations would of course be very much 
non-random, so this could be improved with a pseudo-random scrambling 
function to distribute the addresses in memory. A simple example would 
be to randomly choose a value for one bit in the address for large 
allocations (not necessarily the most significant available but also 
large enough to align 1GB/TB sized allocations if needed), or a bit 
pattern across several address bits for non-even distribution.

The addresses would be also fully randomized inside each priority area.

The division would mean some loss of randomization. A simple rigid 
division of 50%/50% for small vs. large allocations would mean a loss of 
one bit but the above methods could help this. Dividing the address 
space less evenly would improve one side at the expense of the other. 
Cracking the scrambling function would reveal the bit(s) used for the 
division.

It would be nice to remove the current rigid division of the kernel 
address space (Documentation/x86/x86_64/mm.rst) and let the allocations 
be placed more randomly in the entire 47 bit address space. Would the 
above priority scheme (perhaps with a rigid priority for certain users) 
be good enough to allow this?

Even better would be to remove the use of highest bit for selecting 
kernel/user addresses but I suppose it would be a lot of work for 
gaining just one extra bit of randomness. There could be other effects 
though (good or bad).

-Topi

> I'm not even sure that you need to use 'best fit' rather than
> 'first fit'.
> 'best fit' is certainly a lot better for a simple linked list
> user space malloc.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>