From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AIpwx4+Dwy9e3Aj13395jEfVGrs99ukRx59LtAOYTznGX2zApUUB9u4bK0aG1gn4wA9qgUXs5Le/ ARC-Seal: i=1; a=rsa-sha256; t=1522194599; cv=none; d=google.com; s=arc-20160816; b=U115EGT71zpykkgJJF30DjhNZWzLzCa/khzCpjPTKzlKKdOf+QE1Gun78T5VW8JKnL A4dECkLCODDfqAfX+rvle5vL+yR8VC2RB4VQ3J3AC/DEw45k9h7gF9yL5fw+5T4WNY++ Z1rgbhCt9dIQU6hx0RBBW8s8KX194zbzg4K7onKqFxhbiOTEZQnTkXBA3+hRYQhFOloB ++HJ5iicPyaG7OBhQYMYwj4am4c8mplRqSlAh9tYUm0U1FcMfXnd+l1xmHV752iRZ1re GlUEqMr9xwDCvnQDP1hlzKjaUQVLNm8qQxLoWrOE2hvmCd8Sq+T77oZWd0QOOzB0d6po s87g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=8veZ3hdBuONE88dwnYxt9Yf9LP1bUAGz+kemQISA/LA=; b=s2tTenvAHLdeT8ya7UDcsSHia3ay1/aNk+wPrTHG9VFTCYxXn87ryJOVPPhkne0sGV tzYFX5EI9xDVrJZGtgEF8napH2iT5GNsE2lzGgf5K0+jJTcHxkDXX8AIebt7B6/pvV34 5vXw9tROuX696Z9JoiA79KOXTzh9biHZ/2p+eTdwC3+SYR4oT4eSdkjTZL39o2fjlFIq Zgi78yJYRpgl3lqXQNLyyzWXeDlAooQE3eFL1074Bggt+Zv2HvsZePPh8B07HHkPCW+z w4sg+FnETKdHRDkMhG1K0OcXnBV5MNjN+l3jeEEufTDbDEIJU+kDRzxlfHmFMS9BBxBC LkYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20170209 header.b=fjkGm1Qu; spf=pass (google.com: best guess record for domain of willy@infradead.org designates 2607:7c80:54:e::133 as permitted sender) smtp.mailfrom=willy@infradead.org Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20170209 header.b=fjkGm1Qu; spf=pass (google.com: best guess record for domain of willy@infradead.org designates 2607:7c80:54:e::133 as permitted sender) smtp.mailfrom=willy@infradead.org Date: Tue, 27 Mar 2018 16:49:04 -0700 From: Matthew Wilcox To: Kees Cook Cc: Ilya Smith , Michal Hocko , Richard Henderson , ink@jurassic.park.msu.ru, mattst88@gmail.com, Vineet Gupta , Russell King , Tony Luck , Fenghua Yu , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , nyc@holomorphy.com, Al Viro , Arnd Bergmann , Greg KH , Deepa Dinamani , Hugh Dickins , Kate Stewart , Philippe Ombredanne , Andrew Morton , Steve Capper , Punit Agrawal , "Aneesh Kumar K.V" , Nick Piggin , Bhupesh Sharma , Rik van Riel , nitin.m.gupta@oracle.com, "Kirill A. Shutemov" , Dan Williams , Jan Kara , Ross Zwisler , Jerome Glisse , Andrea Arcangeli , Oleg Nesterov , linux-alpha@vger.kernel.org, LKML , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org, Linux MIPS Mailing List , linux-parisc , PowerPC , linux-s390 , linux-sh , sparclinux , Linux-MM Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Message-ID: <20180327234904.GA27734@bombadil.infradead.org> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> <20180326084650.GC5652@dhcp22.suse.cz> <01A133F4-27DF-4AE2-80D6-B0368BF758CD@gmail.com> <20180327072432.GY5652@dhcp22.suse.cz> <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1595656488556903336?= X-GMAIL-MSGID: =?utf-8?q?1596136724900325204?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 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 granularity (over > just base-address offset), so I'd really like to see this supported in > the kernel. We'll be getting there for other things in the future, and > I'd like to have a working production example for researchers to > study, etc. One thing we need is to limit the fragmentation of this approach. Even on 64-bit systems, we can easily get into a situation where there isn't space to map a contiguous terabyte.