> On 5 Mar 2018, at 17:23, Daniel Micay <danielmicay@xxxxxxxxx> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
