Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1830172ybk; Thu, 21 May 2020 16:45:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyYK+wTRdMXW6CWCSNUZ18eKggx7431BwNHFunQ4Wb5Xxg3Z5amc5Ps42QHXjSnrgwODC8V X-Received: by 2002:a50:f391:: with SMTP id g17mr1056924edm.102.1590104734093; Thu, 21 May 2020 16:45:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590104734; cv=none; d=google.com; s=arc-20160816; b=xzQ4I+SWRSzz+Pxtbvt+2yFHSHJCXW4xgCZNpxAEUgpYbtFvIXf4LYu7bYfie1tMBq YQHT6BQfRckR/n9+heDgW8Xn0IRAnlZbLcyXo22J0whcgmmZJh+GTOmNZBfGCPH1STcZ /QmB66556ACCI3ZdgbhJTEacBTWLwpoj+VliIb5DjOSFNZCQseGwAZCFBtBWDKwBhAT8 Xs9NDGmgX6oGmpW8pbDyrkasSTuTqmYiZPCpk443UNZG/RGiBkmgwUsWTTM/xPZC+H5N RZrUBu+Lm5Sgd0ZcOhm5sCo3MKhcFjUH/4lpKCvYhanPe3bLpoBwjTkulxIMMxgNGHmi RvEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from; bh=2nGQ/TlyvcrrYa2Bzhy393Y7AgUO9YLanL8VcMjfgr4=; b=iVrRQCSjGe1mjVAAg5tZSSC8XCKhNBe/U4szI8lyrN4EPmo5zh8HHfnJgR5l4Wjhwy L2yKkIFda8D7SCJFpCRXDS3cBJE4Afdwj1/258U2jfFhE7KaCrreFJRJ7CggJ6LjiRPJ a1tX6GOE964VHlsKG3AsoGfyPXHJsd+vKDrXrI2mlOtgJpNelbqRgWyWP6JCgP3vM91+ 9SXJcl9FEGWmROzmJfmv6ON0CpXbpeSCnzLghZm5WzYl7egCHpx8XNKaO44IK85dN7bG wIODd7TwJmDTByoizpqCQC43KSmeRjmIbjBwwNK/PA+b0aBWnxuc4iDLDrhFJXHLbTpO OlKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u7si4012735ejt.59.2020.05.21.16.45.11; Thu, 21 May 2020 16:45:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729903AbgEUXnd (ORCPT + 99 others); Thu, 21 May 2020 19:43:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728537AbgEUXnc (ORCPT ); Thu, 21 May 2020 19:43:32 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AB01C061A0E for ; Thu, 21 May 2020 16:43:32 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jbuqK-0003mM-IE; Fri, 22 May 2020 01:43:16 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id A0975100CA6; Fri, 22 May 2020 01:43:15 +0200 (CEST) From: Thomas Gleixner To: Kees Cook Cc: Kristen Carlson Accardi , mingo@redhat.com, bp@alien8.de, arjan@linux.intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, rick.p.edgecombe@intel.com Subject: Re: [PATCH v2 0/9] Function Granular KASLR In-Reply-To: <202005211604.86AE1C2@keescook> Date: Fri, 22 May 2020 01:43:15 +0200 Message-ID: <87tv08svl8.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kees, Kees Cook writes: > On Fri, May 22, 2020 at 12:26:30AM +0200, Thomas Gleixner wrote: >> I understand how this is supposed to work, but I fail to find an >> explanation how all of this is preserving the text subsections we have, >> i.e. .kprobes.text, .entry.text ...? > > I had the same question when I first started looking at earlier versions > of this series! :) > >> I assume that the functions in these subsections are reshuffled within >> their own randomized address space so that __xxx_text_start and >> __xxx_text_end markers still make sense, right? > > No, but perhaps in the future. Right now, they are entirely ignored and > left untouched. I'm fine with that restriction, but for a moment I got worried that this might screw up explicit subsections. This really want's to be clearly expressed in the cover letter and the changelogs so that such questions don't arise again. > So, before any of that, just .text.* is a good first step, and after > that I think next would be getting .text randomized relative to the other > .text.* sections (IIUC, it is entirely untouched currently, so only the > standard KASLR base offset moves it around). Only after that do we start > poking around trying to munge the special section contents (which > requires use solving a few problems simultaneously). :) Thanks for the detailed explanation! tglx