From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F490C3F2CD for ; Wed, 4 Mar 2020 09:22:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 27ECA21739 for ; Wed, 4 Mar 2020 09:22:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="LDG8TcPS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725283AbgCDJWT (ORCPT ); Wed, 4 Mar 2020 04:22:19 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:52224 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387644AbgCDJWT (ORCPT ); Wed, 4 Mar 2020 04:22:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Xz1gqS8mHQf0FeXfh5Zn6ODmAjqLlTi3e7QpQPXzA9Q=; b=LDG8TcPSz6KerDK5RXGKXHL0+s nd+daixZ03zWZPBsZex2W0SE2BU+bLdvHBFIbasjYsjLE9O6AcvIE4aklaE3c2rh36+IES5zOiJKo CZHk/ZIgcOCzatmD7F0LvmIA2106SZonTNmKrjs8DuOvT6kzu3GSWHE0zWKaxMKARsPaQGewBXixa ItobUKdK8g+0ymqN8mZ30rSgQf5HEI0PdCrTHBXpOW9woanZqUxWXgFDIr91oXYH//OaNr2XpNsGu Foq59USFJcUjcKrB2RUG0sl7wBvbaaaFVwnCCFfz9rz8IvgRMTSRUVdUbDAj+EcyeoS8xmPTFub7+ KssVL8pg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1j9QDl-0008ML-Jr; Wed, 04 Mar 2020 09:21:41 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id CDE6B30066E; Wed, 4 Mar 2020 10:19:37 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 407052011CA98; Wed, 4 Mar 2020 10:21:36 +0100 (CET) Date: Wed, 4 Mar 2020 10:21:36 +0100 From: Peter Zijlstra To: Kees Cook Cc: Kristen Carlson Accardi , Thomas Garnier , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Kernel Hardening , Herbert Xu , "David S. Miller" , "H. Peter Anvin" , the arch/x86 maintainers , Andy Lutomirski , Juergen Gross , Thomas Hellstrom , "VMware, Inc." , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Rasmus Villemoes , Miguel Ojeda , Will Deacon , Ard Biesheuvel , Masami Hiramatsu , Jiri Slaby , Boris Ostrovsky , Josh Poimboeuf , Cao jin , Allison Randal , Linux Crypto Mailing List , LKML , virtualization@lists.linux-foundation.org, Linux PM list Subject: Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization Message-ID: <20200304092136.GI2596@hirez.programming.kicks-ass.net> References: <20200228000105.165012-1-thgarnie@chromium.org> <202003022100.54CEEE60F@keescook> <20200303095514.GA2596@hirez.programming.kicks-ass.net> <6e7e4191612460ba96567c16b4171f2d2f91b296.camel@linux.intel.com> <202003031314.1AFFC0E@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202003031314.1AFFC0E@keescook> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Tue, Mar 03, 2020 at 01:19:22PM -0800, Kees Cook wrote: > On Tue, Mar 03, 2020 at 01:01:26PM -0800, Kristen Carlson Accardi wrote: > > On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote: > > > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra > > > > But,... do we still need this in the light of that fine-grained > > > > kaslr > > > > stuff? > > > > > > > > What is the actual value of this PIE crud in the face of that? > > > > > > If I remember well, it makes it easier/better but I haven't seen a > > > recent update on that. Is that accurate Kees? > > > > I believe this patchset is valuable if people are trying to brute force > > guess the kernel location, but not so awesome in the event of > > infoleaks. In the case of the current fgkaslr implementation, we only > > randomize within the existing text segment memory area - so with PIE > > the text segment base can move around more, but within that it wouldn't > > strengthen anything. So, if you have an infoleak, you learn the base > > instantly, and are just left with the same extra protection you get > > without PIE. > > Right -- PIE improves both non- and fg- KASLR similarly, in the sense > that the possible entropy for base offset is expanded. It also opens the > door to doing even more crazy things. So I'm really confused. I see it increases the aslr range, but I'm still not sure why we care in the face of fgkaslr. Current kaslr is completely broken because the hardware leaks more bits than we currently have, even without the kernel itself leaking an address. But leaking a single address is not a problem with fgkaslr. > (e.g. why keep the kernel text all > in one contiguous chunk?) Dear gawd, please no. Also, we're limited to 2G text, that's just not a lot of room. I'm really going to object when people propose we introduce direct PLT for x86. > And generally speaking, it seems a nice improvement to me, as it gives > the kernel greater addressing flexibility. But at what cost; it does unspeakable ugly to the asm. And didn't a kernel compiled with the extended PIE range produce a measurably slower kernel due to all the ugly? So maybe I'm slow, but please spell out the benefit, because I'm not seeing it.