> On 29 Mar 2018, at 00:07, Luck, Tony wrote:
>
>> The default limit of only 65536 VMAs will also quickly come into play
>> if consecutive anon mmaps don't get merged. Of course this can be
>> raised, but it has significant resource and performance (fork) costs.
>
> Could
> The default limit of only 65536 VMAs will also quickly come into play
> if consecutive anon mmaps don't get merged. Of course this can be
> raised, but it has significant resource and performance (fork) costs.
Could the random mmap address chooser look for how many existing
VMAs have space
On Fri, Mar 30, 2018 at 09:55:08AM +0200, 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
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 randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation.
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.
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 bypass ASLR in many cases. This patch make
> randomization of
> On 28 Mar 2018, at 02:49, Matthew Wilcox wrote:
>
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it
> 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
>> issue.
>
> You may want to take
> 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 2018, at 11:46, Michal Hocko
On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
Current implementation doesn't randomize address
On Tue, Mar 27, 2018 at 04:49:04PM -0700, Matthew Wilcox wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> > I agree: pushing this off to libc leaves a lot of things unprotected.
> > I think this should live in the kernel. The question I have is about
> > making it
On Tue, Mar 27, 2018 at 6:51 AM, 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 2018, at 11:46, Michal Hocko wrote:
On Fri 23-03-18
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 Mar 2018, at 15:48, Matthew Wilcox wrote:
> >>>
> >>> On Thu, Mar 22, 2018 at
On Fri, Mar 23, 2018 at 12:29:52PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > > implementation to restrict itself to, eg, only loading libraries in
> > > the bottom 1GB
On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> On Fri, Mar 23, 2018 at 05:48:06AM -0700, 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
On Fri, Mar 23, 2018 at 05:48:06AM -0700, 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
> > creation. After that mmap
> 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
>> creation. After
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
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
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR
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
randomization of address on any mmap
20 matches
Mail list logo