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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 21F2DC3F2D1 for ; Tue, 3 Mar 2020 21:19:43 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 7236920870 for ; Tue, 3 Mar 2020 21:19:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="WqGcGMvM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7236920870 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-18056-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 24198 invoked by uid 550); 3 Mar 2020 21:19:36 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 24178 invoked from network); 3 Mar 2020 21:19:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2qU0zyTDNzYtyDUGa9/iXos9xa7ov/2wTakWPxGP1ks=; b=WqGcGMvMn5GluxOGODQRPNpbzgvWO+OkNu8cZEiK4m3NjrW/mP/9I8Ma2MOO/Ww+Rh AXpTLggSqb4nT/DNHZ4zPLZBLfPgo7r9MZEl//d92/3cJAZoUlA/0t9tIJIOzPiz4Vo8 qCIuwYIq9DuCng1+aDxogCJeRnZ7hUGxeizAE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2qU0zyTDNzYtyDUGa9/iXos9xa7ov/2wTakWPxGP1ks=; b=a0ZQK83R5veh1x6skJK9LbgMiNHpZAvQfIjuwWqS+AkC3gGdNVvMjbKV2PHmMPLSrU x3PONxSkPhP9h3GSBfKSw/OF5bAzfBow+KAhXng6XhLSSSRX5JBStee+w0PcM209LkIi AU/U6T/B2qCHkTUXSu0pN5mHpnCh6KVxIMCr25GvZqOUQ+9feIBHtv+pJpn8OrTaoQBf uk5NfvqPVAkOqymyfztdaoBg7oM5UXUIgbjzS2Vxhj+6a352rHB9A0MvfLB9q2IU4Wfd Ra9kIimWJWVZmXipFtGQrL1pnhJGkD/u9QLviFilm00nOm0UlaFain/nDt7ta1LjQze1 N1FQ== X-Gm-Message-State: ANhLgQ1aNaBNFsHK07WolYwG97tZavJX9/ghFNVIjRexKo8XjFEDl/wC bkbgbFYgQUB7kke32xChY/+PqA== X-Google-Smtp-Source: ADFU+vsH9zwFogphrokiom6kP9jpc0/EfWWpx0kYNByJFBy78L6FRZ6b+5u0kGb51gx765tnnhfbdw== X-Received: by 2002:a17:902:8d8a:: with SMTP id v10mr5883926plo.90.1583270363955; Tue, 03 Mar 2020 13:19:23 -0800 (PST) Date: Tue, 3 Mar 2020 13:19:22 -0800 From: Kees Cook To: Kristen Carlson Accardi Cc: Thomas Garnier , Peter Zijlstra , 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: <202003031314.1AFFC0E@keescook> References: <20200228000105.165012-1-thgarnie@chromium.org> <202003022100.54CEEE60F@keescook> <20200303095514.GA2596@hirez.programming.kicks-ass.net> <6e7e4191612460ba96567c16b4171f2d2f91b296.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e7e4191612460ba96567c16b4171f2d2f91b296.camel@linux.intel.com> 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 > > wrote: > > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: > > > > On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote: > > > > > Minor changes based on feedback and rebase from v10. > > > > > > > > > > Splitting the previous serie in two. This part contains > > > > > assembly code > > > > > changes required for PIE but without any direct dependencies > > > > > with the > > > > > rest of the patchset. > > > > > > > > > > Note: Using objtool to detect non-compliant PIE relocations is > > > > > not yet > > > > > possible as this patchset only includes the simplest PIE > > > > > changes. > > > > > Additional changes are needed in kvm, xen and percpu code. > > > > > > > > > > Changes: > > > > > - patch v11 (assembly); > > > > > - Fix comments on x86/entry/64. > > > > > - Remove KASLR PIE explanation on all commits. > > > > > - Add note on objtool not being possible at this stage of > > > > > the patchset. > > > > > > > > This moves us closer to PIE in a clean first step. I think these > > > > patches > > > > look good to go, and unblock the work in kvm, xen, and percpu > > > > code. Can > > > > one of the x86 maintainers pick this series up? > > > > > > 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. (e.g. why keep the kernel text all in one contiguous chunk?) And generally speaking, it seems a nice improvement to me, as it gives the kernel greater addressing flexibility. -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization Date: Tue, 3 Mar 2020 13:19:22 -0800 Message-ID: <202003031314.1AFFC0E@keescook> References: <20200228000105.165012-1-thgarnie@chromium.org> <202003022100.54CEEE60F@keescook> <20200303095514.GA2596@hirez.programming.kicks-ass.net> <6e7e4191612460ba96567c16b4171f2d2f91b296.camel@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <6e7e4191612460ba96567c16b4171f2d2f91b296.camel@linux.intel.com> Sender: linux-crypto-owner@vger.kernel.org To: Kristen Carlson Accardi Cc: Thomas Garnier , Peter Zijlstra , 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 List-Id: virtualization@lists.linuxfoundation.org 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 > > wrote: > > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: > > > > On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote: > > > > > Minor changes based on feedback and rebase from v10. > > > > > > > > > > Splitting the previous serie in two. This part contains > > > > > assembly code > > > > > changes required for PIE but without any direct dependencies > > > > > with the > > > > > rest of the patchset. > > > > > > > > > > Note: Using objtool to detect non-compliant PIE relocations is > > > > > not yet > > > > > possible as this patchset only includes the simplest PIE > > > > > changes. > > > > > Additional changes are needed in kvm, xen and percpu code. > > > > > > > > > > Changes: > > > > > - patch v11 (assembly); > > > > > - Fix comments on x86/entry/64. > > > > > - Remove KASLR PIE explanation on all commits. > > > > > - Add note on objtool not being possible at this stage of > > > > > the patchset. > > > > > > > > This moves us closer to PIE in a clean first step. I think these > > > > patches > > > > look good to go, and unblock the work in kvm, xen, and percpu > > > > code. Can > > > > one of the x86 maintainers pick this series up? > > > > > > 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. (e.g. why keep the kernel text all in one contiguous chunk?) And generally speaking, it seems a nice improvement to me, as it gives the kernel greater addressing flexibility. -- Kees Cook