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  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]
Date:   Wed, 29 Nov 2017 14:15:22 -0800
From:   Kees Cook <>
To:     Rasmus Villemoes <>
Cc:     Michal Hocko <>,
        Linux API <>,
        Khalid Aziz <>,
        Michael Ellerman <>,
        Andrew Morton <>,
        Russell King - ARM Linux <>,
        Andrea Arcangeli <>,
        Linux-MM <>,
        LKML <>,
        linux-arch <>,
        Florian Weimer <>,
        John Hubbard <>,
        Abdul Haleem <>,
        Joel Stanley <>, Michal Hocko <>
Subject: Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Wed, Nov 29, 2017 at 7:13 AM, Rasmus Villemoes
<> wrote:
> On 2017-11-29 15:42, Michal Hocko wrote:
>> The first patch introduced MAP_FIXED_SAFE which enforces the given
>> address but unlike MAP_FIXED it fails with ENOMEM if the given range
>> conflicts with an existing one.
> [s/ENOMEM/EEXIST/, as it seems you also did in the actual patch and
> changelog]
>>The flag is introduced as a completely
>> new one rather than a MAP_FIXED extension because of the backward
>> compatibility. We really want a never-clobber semantic even on older
>> kernels which do not recognize the flag. Unfortunately mmap sucks wrt.
>> flags evaluation because we do not EINVAL on unknown flags. On those
>> kernels we would simply use the traditional hint based semantic so the
>> caller can still get a different address (which sucks) but at least not
>> silently corrupt an existing mapping. I do not see a good way around
>> that.
> I think it would be nice if this rationale was in the 1/2 changelog,
> along with the hint about what userspace that wants to be compatible
> with old kernels will have to do (namely, check that it got what it
> requested) - which I see you did put in the man page.

Okay, so ignore my other email, I must have misunderstood. It _is_,
quite intentionally, being exposed to userspace. Cool by me. :)


Kees Cook
Pixel Security

Powered by blists - more mailing lists