linux-kernel - Re: [PATCHv2 4/5] x86/mm: for MAP_32BIT check in_compat_syscall() instead TIF

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 18 Jan 2017 14:39:54 +0300
From:   Dmitry Safonov <dsafonov@...tuozzo.com>
To:     Andy Lutomirski <luto@...capital.net>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...e.de>, X86 ML <x86@...nel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCHv2 4/5] x86/mm: for MAP_32BIT check in_compat_syscall()
 instead TIF_ADDR32

On 01/17/2017 11:30 PM, Andy Lutomirski wrote:
> On Mon, Jan 16, 2017 at 4:33 AM, Dmitry Safonov <dsafonov@...tuozzo.com> wrote:
>> At this momet, logic in arch_get_unmapped_area{,_topdown} for mmaps with
>> MAP_32BIT flag checks TIF_ADDR32 which means:
>> o if 32-bit ELF changes mode to 64-bit on x86_64 and then tries to
>>   mmap() with MAP_32BIT it'll result in addr over 4Gb (as default is
>>   top-down allocation)
>> o if 64-bit ELF changes mode to 32-bit and tries mmap() with MAP_32BIT,
>>   it'll allocate only memory in 1GB space: [0x40000000, 0x80000000).
>>
>> Fix it by handeling MAP_32BIT in 64-bit syscalls only.
>> As a little bonus it'll make thread flag a little less used.
>
> Seems like an improvement.  Also, jeez, the mmap code is complicated.

Yes, but it's intentionally 4 of 5 by the reason, that it'll broke
the second case:

 >> o if 64-bit ELF changes mode to 32-bit and tries mmap() with MAP_32BIT,
 >>   it'll allocate only memory in 1GB space: [0x40000000, 0x80000000).

if the first 3 patches has not applied earlier.
(because it'll allocate not in 1Gb space, but in 64-bit whole space,
above 4Gb).
So, this should go only after fixing compat mmap in 64-bit binaries,
which is done in prev 3 patches.

-- 
              Dmitry