lkml.org 
[lkml]   [2018]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] Randomization of address chosen by mmap.
From
Date
> On 5 Mar 2018, at 17:23, Daniel Micay <danielmicay@gmail.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

\
 
 \ /
  Last update: 2018-03-05 17:06    [W:0.084 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site