From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) by kanga.kvack.org (Postfix) with ESMTP id 08BE16B0038 for ; Wed, 29 Nov 2017 17:15:25 -0500 (EST) Received: by mail-ua0-f199.google.com with SMTP id k6so3097263uab.21 for ; Wed, 29 Nov 2017 14:15:25 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id v27sor985425uae.75.2017.11.29.14.15.23 for (Google Transport Security); Wed, 29 Nov 2017 14:15:23 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20171129144219.22867-1-mhocko@kernel.org> From: Kees Cook Date: Wed, 29 Nov 2017 14:15:22 -0800 Message-ID: Subject: Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: 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 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 -- Kees Cook Pixel Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org