linux-kernel - Re: [tip:x86/mm] x86/mmap, ASLR: Do not treat unlimited-stack tasks as legacy mmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.20.1706232233020.30709@cbobk.fhfr.pm>
Date:   Fri, 23 Jun 2017 22:35:50 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>, mingo@...nel.org,
        Michal Hocko <mhocko@...e.com>, hpa@...or.com, oleg@...hat.com,
        Thomas Gleixner <tglx@...utronix.de>, davej@...emonkey.org.uk,
        peterz@...radead.org, linux-kernel@...r.kernel.org
cc:     linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/mm] x86/mmap, ASLR: Do not treat unlimited-stack tasks
 as legacy mmap

On Fri, 23 Jun 2017, tip-bot for Michal Hocko wrote:

> TASK_SIZE (allowed by mmap_base) is pretty much unimited in the real
> life. This would give mmap 20TB of additional address space which is
> quite nice. Especially when it is much more likely to use that address
> space than the reserved stack.
> 
> Digging into the history the original implementation of the randomization:
> 
>   8817210d4d96 ("[PATCH] x86_64: Flexmap for 32bit and randomized mappings for 64bit")
> 
> didn't have this restriction.
> 
> So let's try and remove this assumption - hopefully nothing breaks.
> 
> Signed-off-by: Michal Hocko <mhocko@...e.com>
> Cc: Dave Jones <davej@...emonkey.org.uk>
> Cc: Jiri Kosina <jkosina@...e.cz>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: akpm@...ux-foundation.org
> Cc: hughd@...gle.com
> Cc: linux-mm@...ck.org
> Cc: will.deacon@....com
> Link: http://lkml.kernel.org/r/20170614082218.12450-1-mhocko@kernel.org
> [ So I've applied this to tip:x86/mm with a wider Cc: list - if anyone objects to this change please holler. ]
> Signed-off-by: Ingo Molnar <mingo@...nel.org>
> ---
>  arch/x86/mm/mmap.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
> index 19ad095..797295e 100644
> --- a/arch/x86/mm/mmap.c
> +++ b/arch/x86/mm/mmap.c
> @@ -74,9 +74,6 @@ static int mmap_is_legacy(void)
>  	if (current->personality & ADDR_COMPAT_LAYOUT)
>  		return 1;
>  
> -	if (rlimit(RLIMIT_STACK) == RLIM_INFINITY)
> -		return 1;
> -

>From the person who actually added this particular restriction

	Acked-by: Jiri Kosina <jkosina@...e.cz>

I think it was some historical remnant from the times when 32/64 arch code 
split still existed, but can't really recall any details after all those 
years; it doesn't make sense to me any more.

Thanks,

-- 
Jiri Kosina
SUSE Labs