lists.openwall.net | 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 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20171024212119.GB1611@linux.intel.com> Date: Tue, 24 Oct 2017 15:21:19 -0600 From: Ross Zwisler <ross.zwisler@...ux.intel.com> To: Jan Kara <jack@...e.cz> Cc: Dan Williams <dan.j.williams@...el.com>, Ross Zwisler <ross.zwisler@...ux.intel.com>, Christoph Hellwig <hch@...radead.org>, linux-ext4@...r.kernel.org, linux-nvdimm@...ts.01.org, linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org, linux-api@...r.kernel.org, linux-mm@...ck.org, Arnd Bergmann <arnd@...db.de>, Andy Lutomirski <luto@...nel.org>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [PATCH 01/17] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags On Tue, Oct 24, 2017 at 05:23:58PM +0200, Jan Kara wrote: > From: Dan Williams <dan.j.williams@...el.com> > > The mmap(2) syscall suffers from the ABI anti-pattern of not validating > unknown flags. However, proposals like MAP_SYNC need a mechanism to > define new behavior that is known to fail on older kernels without the > support. Define a new MAP_SHARED_VALIDATE flag pattern that is > guaranteed to fail on all legacy mmap implementations. > > It is worth noting that the original proposal was for a standalone > MAP_VALIDATE flag. However, when that could not be supported by all > archs Linus observed: > > I see why you *think* you want a bitmap. You think you want > a bitmap because you want to make MAP_VALIDATE be part of MAP_SYNC > etc, so that people can do > > ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED > | MAP_SYNC, fd, 0); > > and "know" that MAP_SYNC actually takes. > > And I'm saying that whole wish is bogus. You're fundamentally > depending on special semantics, just make it explicit. It's already > not portable, so don't try to make it so. > > Rename that MAP_VALIDATE as MAP_SHARED_VALIDATE, make it have a value > of 0x3, and make people do > > ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED_VALIDATE > | MAP_SYNC, fd, 0); > > and then the kernel side is easier too (none of that random garbage > playing games with looking at the "MAP_VALIDATE bit", but just another > case statement in that map type thing. > > Boom. Done. > > Similar to ->fallocate() we also want the ability to validate the > support for new flags on a per ->mmap() 'struct file_operations' > instance basis. Towards that end arrange for flags to be generically > validated against a mmap_supported_flags exported by 'struct > file_operations'. By default all existing flags are implicitly > supported, but new flags require MAP_SHARED_VALIDATE and > per-instance-opt-in. > > Cc: Jan Kara <jack@...e.cz> > Cc: Arnd Bergmann <arnd@...db.de> > Cc: Andy Lutomirski <luto@...nel.org> > Cc: Andrew Morton <akpm@...ux-foundation.org> > Suggested-by: Christoph Hellwig <hch@....de> > Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org> > Signed-off-by: Dan Williams <dan.j.williams@...el.com> > Signed-off-by: Jan Kara <jack@...e.cz> Looks great. Reviewed-by: Ross Zwisler <ross.zwisler@...ux.intel.com>
Powered by blists - more mailing lists