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
| ||
|
Date: Mon, 13 Nov 2017 15:48:13 +0000 From: Russell King - ARM Linux <linux@...linux.org.uk> To: Michal Hocko <mhocko@...nel.org> Cc: Michael Ellerman <mpe@...erman.id.au>, Joel Stanley <joel@....id.au>, Stephen Rothwell <sfr@...b.auug.org.au>, Andrew Morton <akpm@...ux-foundation.org>, Linux-Next Mailing List <linux-next@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Abdul Haleem <abdhalee@...ux.vnet.ibm.com>, Ralf Baechle <ralf@...ux-mips.org>, "James E.J. Bottomley" <jejb@...isc-linux.org>, Helge Deller <deller@....de>, Yoshinori Sato <ysato@...rs.sourceforge.jp>, Rich Felker <dalias@...c.org>, "David S. Miller" <davem@...emloft.net>, Chris Zankel <chris@...kel.net>, Max Filippov <jcmvbkbc@...il.com>, linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org, linux-mips@...ux-mips.org, linux-parisc@...r.kernel.org, linux-sh@...r.kernel.org, sparclinux@...r.kernel.org, linux-xtensa@...ux-xtensa.org Subject: Re: linux-next: Tree for Nov 7 On Mon, Nov 13, 2017 at 04:16:41PM +0100, Michal Hocko wrote: > On Mon 13-11-17 13:00:57, Michal Hocko wrote: > [...] > > Yes, I have mentioned that in the previous email but the amount of code > > would be even larger. Basically every arch which reimplements > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to > > do vma lookup. > > It turned out that this might be much more easier than I thought after > all. It seems we can really handle that in the common code. This would > mean that we are exposing a new functionality to the userspace though. > Myabe this would be useful on its own though. Just a quick draft (not > even compile tested) whether this makes sense in general. I would be > worried about unexpected behavior when somebody set other bit without a > good reason and we might fail with ENOMEM for such a call now. > > Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED. > --- > diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h > index 3b26cc62dadb..d021c21f9b01 100644 > --- a/arch/alpha/include/uapi/asm/mman.h > +++ b/arch/alpha/include/uapi/asm/mman.h > @@ -31,6 +31,9 @@ > #define MAP_STACK 0x80000 /* give out an address that is best suited for process/thread stacks */ > #define MAP_HUGETLB 0x100000 /* create a huge page mapping */ > > +#define MAP_KEEP_MAPPING 0x2000000 > +#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */ A few things... 1. Does this need to be exposed to userland? 2. Can it end up in include/uapi/asm-generic/mman*.h ? 3. The definition of MAP_FIXED_SAFE should really have parens around it. > @@ -1365,6 +1365,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > if (offset_in_page(addr)) > return addr; > > + if ((flags & MAP_FIXED_SAFE) == MAP_FIXED_SAFE) { I'm surprised this doesn't warn - since this effectively expands to: flags & MAP_FIXED | MAP_KEEP_MAPPING hence why MAP_FIXED_SAFE needs parens. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Powered by blists - more mailing lists