On 5 March 2018 at 08:09, Ilya Smith <blackzert@xxxxxxxxx> wrote: > >> On 4 Mar 2018, at 23:56, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: >> Thinking about this more ... >> >> - When you call munmap, if you pass in the same (addr, length) that were >> used for mmap, then it should unmap the guard pages as well (that >> wasn't part of the patch, so it would have to be added) >> - If 'addr' is higher than the mapped address, and length at least >> reaches the end of the mapping, then I would expect the guard pages to >> "move down" and be after the end of the newly-shortened mapping. >> - If 'addr' is higher than the mapped address, and the length doesn't >> reach the end of the old mapping, we split the old mapping into two. >> I would expect the guard pages to apply to both mappings, insofar as >> they'll fit. For an example, suppose we have a five-page mapping with >> two guard pages (MMMMMGG), and then we unmap the fourth page. Now we >> have a three-page mapping with one guard page followed immediately >> by a one-page mapping with two guard pages (MMMGMGG). > > I’m analysing that approach and see much more problems: > - each time you call mmap like this, you still increase count of vmas as my > patch did > - now feature vma_merge shouldn’t work at all, until MAP_FIXED is set or > PROT_GUARD(0) > - the entropy you provide is like 16 bit, that is really not so hard to brute > - in your patch you don’t use vm_guard at address searching, I see many roots > of bugs here > - if you unmap/remap one page inside region, field vma_guard will show head > or tail pages for vma, not both; kernel don’t know how to handle it > - user mode now choose entropy with PROT_GUARD macro, where did he gets it? > User mode shouldn’t be responsible for entropy at all 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. The VMA count issue is at least something very predictable with a performance cost only for kernel operations. > 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. > 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'm not dictating how things should be done, I don't have any say about that. I'm just trying to discuss it. -- 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
