linux-kernel - Re: [PATCH v5 3/5] mm: introduce mmap3 for safely defining new mmap flags

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPcyv4hGP19iaqvMTUDm6Gu5Tiacm1LFDV7qE-KFnR7pmYK-wg@mail.gmail.com>
Date:   Wed, 16 Aug 2017 09:52:16 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, Jan Kara <jack@...e.cz>,
        Arnd Bergmann <arnd@...db.de>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        Linux API <linux-api@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-xfs@...r.kernel.org, Linux MM <linux-mm@...ck.org>,
        Andy Lutomirski <luto@...nel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v5 3/5] mm: introduce mmap3 for safely defining new mmap flags

On Wed, Aug 16, 2017 at 9:47 AM, Kirill A. Shutemov
<kirill@...temov.name> wrote:
> On Wed, Aug 16, 2017 at 09:35:11AM -0700, Dan Williams wrote:
>> On Wed, Aug 16, 2017 at 4:15 AM, Kirill A. Shutemov
>> <kirill@...temov.name> wrote:
>> > On Wed, Aug 16, 2017 at 12:44:22AM -0700, Dan Williams wrote:
>> >> diff --git a/include/linux/mman.h b/include/linux/mman.h
>> >> index c8367041fafd..0e1de42c836f 100644
>> >> --- a/include/linux/mman.h
>> >> +++ b/include/linux/mman.h
>> >> @@ -7,6 +7,40 @@
>> >>  #include <linux/atomic.h>
>> >>  #include <uapi/linux/mman.h>
>> >>
>> >> +#ifndef MAP_32BIT
>> >> +#define MAP_32BIT 0
>> >> +#endif
>> >> +#ifndef MAP_HUGE_2MB
>> >> +#define MAP_HUGE_2MB 0
>> >> +#endif
>> >> +#ifndef MAP_HUGE_1GB
>> >> +#define MAP_HUGE_1GB 0
>> >> +#endif
>> >> +
>> >> +/*
>> >> + * The historical set of flags that all mmap implementations implicitly
>> >> + * support when file_operations.mmap_supported_mask is zero.
>> >> + */
>> >> +#define LEGACY_MAP_SUPPORTED_MASK (MAP_SHARED \
>> >> +             | MAP_PRIVATE \
>> >> +             | MAP_FIXED \
>> >> +             | MAP_ANONYMOUS \
>> >> +             | MAP_UNINITIALIZED \
>> >> +             | MAP_GROWSDOWN \
>> >> +             | MAP_DENYWRITE \
>> >> +             | MAP_EXECUTABLE \
>> >> +             | MAP_LOCKED \
>> >> +             | MAP_NORESERVE \
>> >> +             | MAP_POPULATE \
>> >> +             | MAP_NONBLOCK \
>> >> +             | MAP_STACK \
>> >> +             | MAP_HUGETLB \
>> >> +             | MAP_32BIT \
>> >> +             | MAP_HUGE_2MB \
>> >> +             | MAP_HUGE_1GB)
>> >> +
>> >> +#define      MAP_SUPPORTED_MASK (LEGACY_MAP_SUPPORTED_MASK)
>> >> +
>> >>  extern int sysctl_overcommit_memory;
>> >>  extern int sysctl_overcommit_ratio;
>> >>  extern unsigned long sysctl_overcommit_kbytes;
>> >
>> > Since we looking into mmap(2) ABI, maybe we should consider re-defining
>> > MAP_DENYWRITE and MAP_EXECUTABLE as 0 in hope that we would be able to
>> > re-use these bits in the future? These flags are ignored now anyway.
>>
>> Yes, we can make these -EOPNOTSUPP in the new syscall.
>
> You cannot detect them, if we would redefine them as 0. :)

Yes, we can, there will now be missing bits in
LEGACY_MAP_SUPPORTED_MASK that will fail those bit values until we
re-define them. Everything else is a an exercise for libc about what
it wants to do when it sees those values.