> On 30 Mar 2018, at 12:57, Pavel Machek wrote:
>
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>>
>>> On 30 Mar 2018, at 10:55, Pavel Machek wrote:
>>>
>>> Hi!
>>>
>>>> Current implementation doesn't r
Hi
> On 30 Mar 2018, at 10:55, Pavel Machek wrote:
>
> Hi!
>
>> 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 byp
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o wrote:
>
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a
>> performance
>>
> On 27 Mar 2018, at 17:38, Michal Hocko wrote:
>
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>
>>> On 27 Mar 2018, at 10:24, Michal Hocko wrote:
>>>
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>>
>>>>> On 26 Mar
> On 27 Mar 2018, at 10:24, Michal Hocko wrote:
>
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>
>>> On 26 Mar 2018, at 11:46, Michal Hocko wrote:
>>>
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>
>>>>> On 23 M
> On 26 Mar 2018, at 11:46, Michal Hocko wrote:
>
> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>
>>> On 23 Mar 2018, at 15:48, Matthew Wilcox wrote:
>>>
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current imp
> On 23 Mar 2018, at 15:48, Matthew Wilcox wrote:
>
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> crea
> On 22 Mar 2018, at 23:54, Andrew Morton wrote:
>
>
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present this
> is just a lump of random
> On 22 Mar 2018, at 23:53, Andrew Morton wrote:
>
> On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith wrote:
>
>> include/linux/mm.h | 16 --
>> mm/mmap.c | 164
>> +
>
> You'
Hello, Andrew
Thanks for reading this patch.
> On 22 Mar 2018, at 23:57, Andrew Morton wrote:
>
> On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith wrote:
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing
Signed-off-by: Ilya Smith
---
include/linux/mm.h | 16 --
mm/mmap.c | 164 +
2 files changed, 175 insertions(+), 5 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42..c716257 100644
--- a/include
9s
sys 1m4.969s
echo 4 > /proc/sys/kernel/randomize_va_space
make mrproper && make defconfig && time make
real11m12.806s
user10m18.305s
sys 1m4.281s
Ilya Smith (2):
Randomization of address chosen by mmap.
Architecture defined limit on memory region random shift.
ar
Signed-off-by: Ilya Smith
---
arch/alpha/kernel/osf_sys.c | 1 +
arch/arc/mm/mmap.c | 1 +
arch/arm/mm/mmap.c | 2 ++
arch/frv/mm/elf-fdpic.c | 1 +
arch/ia64/kernel/sys_ia64.c | 1 +
arch/ia64/mm/hugetlbpage.c | 1 +
arch
> 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 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
>>
> 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 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 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 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
> 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
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
>
> mmap_min_addr handling is a bit mess... As you say, we would return
> EPERM rather than ENOMEM which can be confusing but depleting the
> address space like that is quite unlikely on 64b unless I am missing.
> It is good to be in sync here with the generic implementation though,
> IMO.
>
If
make randomization of address on any mmap call.
It works good on 64 bit system, but usage under 32 bit systems is not
recommended. This approach uses current implementation to simplify search
of address.
Here I would like to discuss this approach.
Signed-off-by: Ilya Smith
---
include/linux/mm.h
Thanks for that, I will fix it in next patch. Any other feedback?
Thanks,
Ilya
> 26 февр. 2018 г., в 20:48, Randy Dunlap написал(а):
>
> On 02/26/2018 07:46 AM, Ilya Smith wrote:
>> Signed-off-by: Ilya Smith
>> ---
&g
-by: Ilya Smith
---
arch/x86/kernel/sys_x86_64.c | 5 +++--
arch/x86/mm/mmap.c | 4
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 676774b9bb8d..1752fe5cb735 100644
--- a/arch/x86/kernel/sys_x86_64.c
m ELF file.
Ilya Smith (1):
Additional strict check on ELF file. Checks segments are followed in
order of 'p_vaddr ' value ascending. It fixes erorr in
total_mapping_size with computation total size. This error happens
if segments in ELF file are not in order.
fs/bi
Signed-off-by: Ilya Smith
---
fs/binfmt_elf.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index bdb201230bae..970b42044240 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -524,6 +524,52 @@ static
28 matches
Mail list logo
