Date:   Tue, 27 Mar 2018 16:51:08 +0300
From:   Ilya Smith <blackzert@...il.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Matthew Wilcox <willy@...radead.org>, rth@...ddle.net,
        ink@...assic.park.msu.ru, mattst88@...il.com, vgupta@...opsys.com,
        linux@...linux.org.uk, tony.luck@...el.com, fenghua.yu@...el.com,
        ralf@...ux-mips.org, jejb@...isc-linux.org,
        Helge Deller <deller@....de>, benh@...nel.crashing.org,
        paulus@...ba.org, mpe@...erman.id.au, schwidefsky@...ibm.com,
        heiko.carstens@...ibm.com, ysato@...rs.sourceforge.jp,
        dalias@...c.org, davem@...emloft.net, tglx@...utronix.de,
        mingo@...hat.com, hpa@...or.com, x86@...nel.org,
        nyc@...omorphy.com, viro@...iv.linux.org.uk, arnd@...db.de,
        gregkh@...uxfoundation.org, deepa.kernel@...il.com,
        Hugh Dickins <hughd@...gle.com>, kstewart@...uxfoundation.org,
        pombredanne@...b.com, Andrew Morton <akpm@...ux-foundation.org>,
        steve.capper@....com, punit.agrawal@....com,
        aneesh.kumar@...ux.vnet.ibm.com, npiggin@...il.com,
        Kees Cook <keescook@...omium.org>, bhsharma@...hat.com,
        riel@...hat.com, nitin.m.gupta@...cle.com,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Jan Kara <jack@...e.cz>, ross.zwisler@...ux.intel.com,
        Jerome Glisse <jglisse@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Oleg Nesterov <oleg@...hat.com>, linux-alpha@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        linux-snps-arc@...ts.infradead.org, linux-ia64@...r.kernel.org,
        linux-metag@...r.kernel.org, linux-mips@...ux-mips.org,
        linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
        sparclinux@...r.kernel.org, Linux-MM <linux-mm@...ck.org>
Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.


> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@...nel.org> wrote:
> 
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>> 
>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@...nel.org> wrote:
>>> 
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>> 
>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@...radead.org> wrote:
>>>>> 
>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>> creation. After that mmap build very predictable layout of address
>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>> randomization of address on any mmap call.
>>>>> 
>>>>> Why should this be done in the kernel rather than libc?  libc is perfectly
>>>>> capable of specifying random numbers in the first argument of mmap.
>>>> Well, there is following reasons:
>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>> 
>>> Is this really so helpful?
>> 
>> Yes, ASLR is one of very important mitigation techniques which are really used 
>> to protect applications. If there is no ASLR, it is very easy to exploit 
>> vulnerable application and compromise the system. We can’t just fix all the 
>> vulnerabilities right now, thats why we have mitigations - techniques which are 
>> makes exploitation more hard or impossible in some cases.
>> 
>> Thats why it is helpful.
> 
> I am not questioning ASLR in general. I am asking whether we really need
> per mmap ASLR in general. I can imagine that some environments want to
> pay the additional price and other side effects, but considering this
> can be achieved by libc, why to add more code to the kernel?

I believe this is the only one right place for it. Adding these 200+ lines of 
code we give this feature for any user - on desktop, on server, on IoT device, 
on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA 
devices will never get it.

>>> 
>>>> 2. User mode is not that layer which should be responsible for choosing
>>>> random address or handling entropy;
>>> 
>>> Why?
>> 
>> Because of the following reasons:
>> 1. To get random address you should have entropy. These entropy shouldn’t be 
>> exposed to attacker anyhow, the best case is to get it from kernel. So this is
>> a syscall.
> 
> /dev/[u]random is not sufficient?

Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
issue.

> 
>> 2. You should have memory map of your process to prevent remapping or big
>> fragmentation. Kernel already has this map.
> 
> /proc/self/maps?

Not any system has /proc and parsing /proc/self/maps is robust so it is the 
performance issue. libc will have to do it on any mmap. And there is a possible 
race here - application may mmap/unmap memory with native syscall during other 
thread reading maps.

>> You will got another one in libc.
>> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
>> This one also decrease performance cause you any way call syscall_mmap 
>> which will try to find some address for you in worst case, but after you already
>> did some computing on it.
> 
> I do not understand. a) you should be prepared to pay an additional
> price for an additional security measures and b) how would anybody punch
> a hole into your mapping? 
> 

I was talking about any code that call mmap directly without libc wrapper.

>> 3. The more memory you use in userland for these proposal, the easier for
>> attacker to leak it or use in exploitation techniques.
> 
> This is true in general, isn't it? I fail to see how kernel chosen and
> user chosen ranges would make any difference.

My point here was that libc will have to keep memory representation as a tree 
and this tree increase attack surface. It could be hidden in kernel as it is right now.

> 
>> 4. It is so easy to fix Kernel function and so hard to support memory
>> management from userspace.
> 
> Well, on the other hand the new layout mode will add a maintenance
> burden on the kernel and will have to be maintained for ever because it
> is a user visible ABI.

Thats why I made this patch as RFC and would like to discuss this ABI here. I 
made randomize_va_space parameter to allow disable randomisation per whole 
system. PF_RANDOMIZE flag may disable randomization for concrete process (or 
process groups?). For architecture I’ve made info.random_shift = 0 , so if your 
arch has small address space you may disable shifting. I also would like to add 
some sysctl to allow process/groups to change this value and allow some 
processes to have shifts bigger then another. Lets discuss it, please.

> 
>>>> 3. Memory fragmentation is unpredictable in this case
>>>> 
>>>> Off course user mode could use random ‘hint’ address, but kernel may
>>>> discard this address if it is occupied for example and allocate just before
>>>> closest vma. So this solution doesn’t give that much security like 
>>>> randomization address inside kernel.
>>> 
>>> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
>>> address range atomically and chose a different range on failure.
>>> 
>> 
>> This algorithm should track current memory. If he doesn’t he may cause
>> infinite loop while trying to choose memory. And each iteration increase time
>> needed on allocation new memory, what is not preferred by any libc library
>> developer.
> 
> Well, I am pretty sure userspace can implement proper free ranges
> tracking…

I think we need to know what libc developers will say on implementing ASLR in 
user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem 
of ASLR will stay forever.

Thanks,
Ilya

Powered by blists - more mailing lists