[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <896E6047-A49F-4E2E-A831-34CC2AD48550@gmail.com>
Date: Mon, 5 Mar 2018 19:05:08 +0300
From: Ilya Smith <blackzert@...il.com>
To: Daniel Micay <danielmicay@...il.com>
Cc: Matthew Wilcox <willy@...radead.org>,
Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Dan Williams <dan.j.williams@...el.com>,
Michal Hocko <mhocko@...e.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Jan Kara <jack@...e.cz>,
Jerome Glisse <jglisse@...hat.com>,
Hugh Dickins <hughd@...gle.com>,
Helge Deller <deller@....de>,
Andrea Arcangeli <aarcange@...hat.com>,
Oleg Nesterov <oleg@...hat.com>,
Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [RFC PATCH] Randomization of address chosen by mmap.
> On 5 Mar 2018, at 17:23, Daniel Micay <danielmicay@...il.com> wrote:
> I didn't suggest this as the way of implementing fine-grained
> randomization but rather a small starting point for hardening address
> space layout further. I don't think it should be tied to a mmap flag
> but rather something like a personality flag or a global sysctl. It
> doesn't need to be random at all to be valuable, and it's just a first
> step. It doesn't mean there can't be switches between random pivots
> like OpenBSD mmap, etc. I'm not so sure that randomly switching around
> is going to result in isolating things very well though.
>
Here I like the idea of Kees Cook:
> I think this will need a larger knob -- doing this by default is
> likely to break stuff, I'd imagine? Bikeshedding: I'm not sure if this
> should be setting "3" for /proc/sys/kernel/randomize_va_space, or a
> separate one like /proc/sys/mm/randomize_mmap_allocation.
I mean it should be a way to turn randomization off since some applications are
really need huge memory.
If you have suggestion here, would be really helpful to discuss.
I think one switch might be done globally for system administrate like
/proc/sys/mm/randomize_mmap_allocation and another one would be good to have
some ioctl to switch it of in case if application knows what to do.
I would like to implement it in v2 of the patch.
>> I can’t understand what direction this conversation is going to. I was talking
>> about weak implementation in Linux kernel but got many comments about ASLR
>> should be implemented in user mode what is really weird to me.
>
> That's not what I said. I was saying that splitting things into
> regions based on the type of allocation works really well and allows
> for high entropy bases, but that the kernel can't really do that right
> now. It could split up code that starts as PROT_EXEC into a region but
> that's generally not how libraries are mapped in so it won't know
> until mprotect which is obviously too late. Unless it had some kind of
> type key passed from userspace, it can't really do that.
Yes, thats really true. I wrote about earlier. This is the issue - kernel can’t
provide such interface thats why I try to get maximum from current mmap design.
May be later we could split mmap on different actions by different types of
memory it handles. But it will be a very long road I think.
>> I think it is possible to add GUARD pages into my implementations, but initially
>> problem was about entropy of address choosing. I would like to resolve it step by
>> step.
>
> Starting with fairly aggressive fragmentation of the address space is
> going to be a really hard sell. The costs of a very spread out address
> space in terms of TLB misses, etc. are unclear. Starting with enforced
> gaps (1 page) and randomization for those wouldn't rule out having
> finer-grained randomization, like randomly switching between different
> regions. This needs to be cheap enough that people want to enable it,
> and the goals need to be clearly spelled out. The goal needs to be
> clearer than "more randomization == good" and then accepting a high
> performance cost for that.
>
I want to clarify. As I know TLB caches doesn’t care about distance between
pages, since it works with pages. So in theory TLB miss is not an issue here. I
agree, I need to show the performance costs here. I will. Just give some time
please.
The enforced gaps, in my case:
+ addr = get_random_long() % ((high - low) >> PAGE_SHIFT);
+ addr = low + (addr << PAGE_SHIFT);
but what you saying, entropy here should be decreased.
How about something like this:
+ addr = get_random_long() % min(((high - low) >> PAGE_SHIFT),
MAX_SECURE_GAP );
+ addr = high - (addr << PAGE_SHIFT);
where MAX_SECURE_GAP is configurable. Probably with sysctl.
How do you like it?
> I'm not dictating how things should be done, I don't have any say
> about that. I'm just trying to discuss it.
Sorry, thanks for your involvement. I’m really appreciate it.
Thanks,
Ilya
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
