Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1225157

Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

Show all headers | View raw

On Tue, Sep 15, 2015 at 12:42:00PM +0300, Kirill A. Shutemov wrote:
> On Mon, Sep 14, 2015 at 10:19:19PM -0700, Josh Triplett wrote:
> > On Tue, Sep 15, 2015 at 03:23:58AM +0300, Kirill A. Shutemov wrote:
> > > On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
> > > > This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
> > > > userspace wouldn't actually ever see it be non-zero.  While I could
> > > > have kept hiding it, the man pages seem to indicate that
> > > > MAP_UNINITIALIZED should be visible:
> > > > 
> > > >   mmap(2)
> > > >   MAP_UNINITIALIZED (since Linux 2.6.33)
> > > >     Don't clear anonymous pages.  This flag is intended to improve
> > > >     performance on embedded devices.  This flag is honored only if the
> > > >     kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED
> > > >     option.  Because of the security implications, that option is
> > > >     normally enabled only on embedded devices (i.e., devices where one
> > > >     has complete control of the contents of user memory).
> > > > 
> > > > and since the only time it shows up in my /usr/include is in this
> > > > header I believe this should have been visible to userspace (as
> > > > non-zero, which wouldn't do anything when or'd into the flags) all
> > > > along.
> > > 
> > > Are you sure about "wouldn't do anything"?
> > > Suspiciously, 0x4000000 is also (1 << MAP_HUGE_SHIFT). I'm not sure if any
> > > architecture has order-1 huge pages, but still looks like we have conflict
> > > here.
> > > 
> > > I think it's harmful to expose non-zero MAP_UNINITIALIZED to system which
> > > potentially can handle multiple users. Or non-trivial user space in
> > > general.
> > 
> > The flag should always exist.
> 
> Sure. And 0 is perfectly fine value for the flag. Like with MAP_FILE.

Rephrasing: the flag should always exist with the correct value.
Whether the kernel handles it or not, the kernel *headers* shouldn't
change to match the kernel, not least of which because they don't
necessarily match the running kernel.  Just like we define the
prototypes for syscalls that the running kernel may return ENOSYS for.

> > If it was defined to conflict with
> > something else, that's a serious ABI problem.  But the flag
> > should always exist, even if the kernel ends up ignoring it.
> > 
> > > Should we leave it at least under '#ifndef CONFIG_MMU'? I don't think it's
> > > possible to have single ABI for MMU and MMU-less systems anyway. And we
> > > can avoid conflict with MAP_HUGE_SHIFT this way.
> > 
> > No; even if you have an MMU (which is useful for things like fork()), a
> > system without user separation (for instance, without CONFIG_MULTIUSER)
> > can reasonably use MAP_UNINITIALIZED.
> 
> Can? Yes. Reasonably? I don't think so.

Not all systems care.  Otherwise you should be complaining more bitterly
about options like CONFIG_MMU=n, which (*gasp*) allow access to *arbitrary
memory*.

> > > P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
> > > mailing list on why it was allowed.
> > 
> > That's what the config option *and* explicit flag are for; there are
> > more than enough warnings about the implications.
> 
> I think it's misdesigned. It doesn't require explicid opt-in from a
> process who owned the page allocated in MAP_UNINITIALIZED mapping before.
> 
> #define MAP_LEAK_ME_SOME_DATA MAP_UNINITIALIZED

Hence why it has a config option.

The userspace option exists primarily because otherwise userspace might
get surprised by receiving a non-zeroed page.  On a system with the
config option turned on, processes have access to arbitrary freed
memory, as long as they say they can handle not having their memory
pre-zeroed.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:10 +0200
  [PATCH 06/13] Hide ep_take_care_of_epollwakeup() behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
  [PATCH 11/13] Hide MAX_RAW_MINORS behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
    Re: [PATCH 11/13] Hide MAX_RAW_MINORS behind #ifdef __KERNEL__ David Howells <dhowells@redhat.com> - 2015-09-10 13:20 +0200
  [PATCH 02/13] Always expose __SYSCALL(... fork ...) Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
  [PATCH 13/13] Re-enable and clean up "check_config()" in headers_check.pl Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
  [PATCH 05/13] Hide some of "struct elf_prstatus" behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
  [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
  [PATCH 03/13] Hide COMPAT_ATM_ADDPARTY behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
  [PATCH 08/13] Hide MAX_SHARED_LIBS behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
  Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h David Howells <dhowells@redhat.com> - 2015-09-10 13:20 +0200
    Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h David Howells <dhowells@redhat.com> - 2015-09-10 13:20 +0200
      Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
  [PATCH 06/13] Move ep_take_care_of_epollwakeup() to fs/eventpoll.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
  [PATCH 02/13] Use sys_ni.c instead of #ifdef to disable fork on CONFIG_NOMMU Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
  [PATCH 01/13] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
  [PATCH 05/13] Split FDPIC "struct elf_prstatus" to "struct elf_fdpic_prstatus" Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    Re: [PATCH 05/13] Split FDPIC "struct elf_prstatus" to "struct elf_fdpic_prstatus" David Howells <dhowells@redhat.com> - 2015-09-17 12:20 +0200
  [PATCH v3] Remove #ifdef CONFIG_* from all userspace headers Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Peter Zijlstra <peterz@infradead.org> - 2015-09-15 10:10 +0200
        Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 20:50 +0200
          Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Peter Zijlstra <peterz@infradead.org> - 2015-09-15 21:40 +0200
            Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-17 06:00 +0200
        Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Arnd Bergmann <arnd@arndb.de> - 2015-09-15 23:20 +0200
          Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c David Howells <dhowells@redhat.com> - 2015-09-17 12:30 +0200
    [PATCH 13/13] Re-enable and clean up "check_config()" in headers_check.pl Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-15 02:30 +0200
        Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 03:00 +0200
        Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Josh Triplett <josh@joshtriplett.org> - 2015-09-15 07:20 +0200
          Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-15 11:50 +0200
            Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Josh Triplett <josh@joshtriplett.org> - 2015-09-15 16:20 +0200
              Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace David Howells <dhowells@redhat.com> - 2015-09-17 12:20 +0200
    [PATCH 08/13] Move MAX_SHARED_LIBS to fs/binfmt_flat.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 07/13] Make FB_BACKLIGHT_{LEVELS,MAX} always visible Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 12/13] Remove AT_VECTOR_SIZE_ARCH on x86 Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      Re: [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace "H. Peter Anvin" <hpa@zytor.com> - 2015-09-15 22:50 +0200
        Re: [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-17 05:10 +0200
    [PATCH 10/13] Move USE_WCACHING to drivers/block/pktcdvd.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      Re: [PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c David Howells <dhowells@redhat.com> - 2015-09-17 12:00 +0200
        Re: [PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-17 23:00 +0200

csiph-web