> On 5 Mar 2018, at 22:47, Matthew Wilcox wrote:
- the entropy you provide is like 16 bit, that is really not so hard to
brute
>>>
>>> It's 16 bits per mapping. I think that'll make enough attacks harder
>>> to be worthwhile.
>>
>> Well yes, its ok, sorry. I just would like to have 3
On Mon, Mar 05, 2018 at 10:27:32PM +0300, Ilya Smith wrote:
> > On 5 Mar 2018, at 19:23, Matthew Wilcox wrote:
> > On Mon, Mar 05, 2018 at 04:09:31PM +0300, Ilya Smith wrote:
> >> I’m analysing that approach and see much more problems:
> >> - each time you call mmap like this, you still increase
> On 5 Mar 2018, at 19:23, Matthew Wilcox wrote:
>
> On Mon, Mar 05, 2018 at 04:09:31PM +0300, Ilya Smith wrote:
>>
>> 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
>
> Umm ... yes, each t
On Mon, Mar 05, 2018 at 04:09:31PM +0300, Ilya Smith wrote:
> > On 4 Mar 2018, at 23:56, Matthew Wilcox 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
> On 5 Mar 2018, at 17:23, Daniel Micay 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 fl
On 5 March 2018 at 08:09, Ilya Smith wrote:
>
>> On 4 Mar 2018, at 23:56, Matthew Wilcox 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
> On 4 Mar 2018, at 23:56, Matthew Wilcox 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 'a
On Sat, Mar 03, 2018 at 07:47:04PM -0800, Matthew Wilcox wrote:
> On Sat, Mar 03, 2018 at 04:00:45PM -0500, Daniel Micay wrote:
> > The main thing I'd like to see is just the option to get a guarantee
> > of enforced gaps around mappings, without necessarily even having
> > randomization of the gap
On Sat, Mar 03, 2018 at 04:00:45PM -0500, Daniel Micay wrote:
> The main thing I'd like to see is just the option to get a guarantee
> of enforced gaps around mappings, without necessarily even having
> randomization of the gap size. It's possible to add guard pages in
> userspace but it adds overh
On 3 March 2018 at 08:58, Ilya Smith wrote:
> Hello Daniel, thanks for sharing you experience!
>
>> On 1 Mar 2018, at 00:02, Daniel Micay wrote:
>>
>> I don't think it makes sense for the kernel to attempt mitigations to
>> hide libraries. The best way to do that is in userspace, by having the
>>
> On 2 Mar 2018, at 23:48, Matthew Wilcox wrote:
> Ah, I didn't mean that. I was thinking that we can change the
> implementation to reserve 1-N pages after the end of the mapping.
> So you can't map anything else in there, and any load/store into that
> region will segfault.
>
I’m afraid it st
Hello Daniel, thanks for sharing you experience!
> On 1 Mar 2018, at 00:02, Daniel Micay wrote:
>
> I don't think it makes sense for the kernel to attempt mitigations to
> hide libraries. The best way to do that is in userspace, by having the
> linker reserve a large PROT_NONE region for mapping
On Fri, Mar 02, 2018 at 11:30:28PM +0300, Ilya Smith wrote:
> This is a really good question. Lets think we choose address with
> random-length
> guard hole. This length is limited by some configuration as you described.
> For
> instance let it be 1MB. Now according to current implementation, w
> On 28 Feb 2018, at 21:33, Matthew Wilcox wrote:
>
> On Wed, Feb 28, 2018 at 08:13:00PM +0300, Ilya Smith wrote:
>>> It would be worth spelling out the "not recommended" bit some more
>>> too: this fragments the mmap space, which has some serious issues on
>>> smaller address spaces if you get i
> On 28 Feb 2018, at 22:54, Kees Cook wrote:
>
> I was trying to understand the target entropy level, and I'm worried
> it's a bit biased. For example, if the first allocation lands at 1/4th
> of the memory space, the next allocation (IIUC) has a 50% chance of
> falling on either side of it. If
The option to add at least one guard page would be useful whether or
not it's tied to randomization. It's not feasible to do that in
userspace for mmap as a whole, only specific users of mmap like malloc
and it adds significant overhead vs. a kernel implementation. It could
optionally let you choos
On Wed, Feb 28, 2018 at 9:13 AM, Ilya Smith wrote:
>> On 27 Feb 2018, at 23:52, Kees Cook wrote:
>> What are the two phases here? Could this second one get collapsed into
>> the first?
>>
>
> Let me explain.
> 1. we use current implementation to get larger address. Remember it as
> ‘right_vma’.
>
On Wed, Feb 28, 2018 at 08:13:00PM +0300, Ilya Smith wrote:
> > It would be worth spelling out the "not recommended" bit some more
> > too: this fragments the mmap space, which has some serious issues on
> > smaller address spaces if you get into a situation where you cannot
> > allocate a hole lar
Hello Kees,
Thanks for your time spent on that!
> On 27 Feb 2018, at 23:52, Kees Cook wrote:
>
> I'd like more details on the threat model here; if it's just a matter
> of .so loading order, I wonder if load order randomization would get a
> comparable level of uncertainty without the memory fr
On 2/27/18 9:52 PM, Kees Cook wrote:
> I'd like more details on the threat model here; if it's just a matter
> of .so loading order, I wonder if load order randomization would get a
> comparable level of uncertainty without the memory fragmentation,
This also seems to assume that leaking the add
On Tue, Feb 27, 2018 at 5:13 AM, Ilya Smith wrote:
> This is more proof of concept. 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
This is more proof of concept. 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 random
22 matches
Mail list logo
