[lkml]   [2015]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace
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

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

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.

P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
mailing list on why it was allowed.
But that's other topic.

Kirill A. Shutemov

 \ /
  Last update: 2015-09-15 02:41    [W:0.301 / U:2.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site