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
| ||
|
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
Powered by blists - more mailing lists