Messages in this thread |  | | Date | Tue, 15 Sep 2015 03:23:58 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [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 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.
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
|  |