Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> 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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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.

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> 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 randomize address returned by mmap. All the

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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.

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> 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

RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> 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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> 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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> 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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue, Mar 27, 2018 at 06:16:35PM -0400, 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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue, Mar 27, 2018 at 4:49 PM, 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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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 maintainable/readable/etc. > > The state-of-the-art for ASLR is moving to finer

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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 a look at the getrandom(2) system call, which is the recommended way getting

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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 wrote: > >>> > >>> On Fri 23-03-18 20:55:49, Ilya Smith

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> 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 Mar 2018, at 15:48, Matthew Wilcox

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> 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 implementation

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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 implementation doesn't randomize address returned by mmap. > >> All the entropy ends with

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Fri, Mar 23, 2018 at 12:06:18PM -0700, 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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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 to avoid applications who want to map huge things from > > running out

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by 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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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 mmap_base_addr at the process > creation. After that mmap build very predictable layout of address > space. It