On Wed, Nov 29, 2017 at 7:13 AM, Rasmus Villemoes <rasmus.villemoes@xxxxxxxxx> 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
