lkml.org 
[lkml]   [2017]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE
    On Wed, Nov 29, 2017 at 7:13 AM, Rasmus Villemoes
    <rasmus.villemoes@prevas.dk> 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

    --
    Kees Cook
    Pixel Security

    \
     
     \ /
      Last update: 2017-11-29 23:15    [W:4.287 / U:0.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site