[RFC PATCH v2 0/2] Randomization of address chosen by mmap.

Kees Cook keescook at chromium.org
Tue Mar 27 16:57:43 PDT 2018


On Tue, Mar 27, 2018 at 4:49 PM, Matthew Wilcox <willy at infradead.org> wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported in
>> the kernel. We'll be getting there for other things in the future, and
>> I'd like to have a working production example for researchers to
>> study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.

FWIW, I wouldn't expect normal systems to use this. I am curious about
fragmentation vs entropy though. Are workloads with a mis of lots of
tiny allocations and TB-allocations? AIUI, glibc uses larger mmap()
regions for handling tiny mallocs().

-Kees

-- 
Kees Cook
Pixel Security



More information about the linux-snps-arc mailing list