Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp818640ybg; Tue, 9 Jun 2020 13:44:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwA1/k/ff3TEzv94MtBGto6BhSeSrkHaWc2gDw4nzH8MFHl5Ol+sXxWw1TVJEE+SafT619B X-Received: by 2002:a05:6402:7d4:: with SMTP id u20mr28114799edy.30.1591735450127; Tue, 09 Jun 2020 13:44:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591735450; cv=none; d=google.com; s=arc-20160816; b=AvaoiaXBFElyAEXzQLfVM7+ZUzVDC9CD3o0fGvmx8X0f/cMMqCVhgM18fN69FLlIz6 OlsGoj32H3AEsmLUI9CTrpktlaT9xEv5+aSU9hWjfA1w20aJMmV0otWfA5kWW6LK6LaL gl21a03v9NOMN54a9qSU/oECaLDCES9IMRCHX/WwsyCZDLP5QYMcVvcPJ1Y4qqTCdc1t s73KmhJkl/2yTe71MQKTi3w+3svWSLvQcQRokgJ6kaCt+bzPXqPwxKetoWsxB0KWQunR C+Re/m4i4GPHmvONg40E73SDs8D65+XQp93lPrJJuBqKQyGhA7i4zxjFp9XuGjN72dv5 NvYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=S1vBKT0yWnLuB7U8YX8ngGZwmaPvDRzzZCxacO5i+2o=; b=KGr4/czSQYCRFTnU7kM3Uqg3/T681+vMke7r2i05sEYVfgD5S52vyNMCrvxDYb7NY+ 20CnDlfKliCl4TZBYlWV2AJomPs0kMoi4nZTAwDMU/YiHxtzUDP5RU8pII7tq/6dQasm DLtvMt9V9u833R8BwrDaMphCnCCscLqjoM1wqaAFMALYCzB1KNekIEGIEemrHK7XK/zg vwN0iByqfW55tuzACKUheMUKr1+Ol570BTFn/pknRWsW4NnwDSI4w6F9/XivuWIXOJnL CEDtkl8fajwxMpTApTfuZvB6HNKudxABOANmQj7nYX/QIuEfj8CrA/R91N7bagkX9qEi clTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YrIcM+oZ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ds7si16992828ejc.717.2020.06.09.13.43.47; Tue, 09 Jun 2020 13:44:10 -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; dkim=pass header.i=@chromium.org header.s=google header.b=YrIcM+oZ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728648AbgFIUmF (ORCPT + 99 others); Tue, 9 Jun 2020 16:42:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727098AbgFIUmE (ORCPT ); Tue, 9 Jun 2020 16:42:04 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC97FC05BD1E for ; Tue, 9 Jun 2020 13:42:02 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id m2so1914958pjv.2 for ; Tue, 09 Jun 2020 13:42:02 -0700 (PDT) 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=S1vBKT0yWnLuB7U8YX8ngGZwmaPvDRzzZCxacO5i+2o=; b=YrIcM+oZzwpQaYRF0+ivYfdkE5+At1SGS3X9EkfMcFYnQ+ao3zSFVraPEM6FbJ8twK HBHi4qmnExk02NZLB0ffAs8BamSKAcrwlwQAzlslHSqCzDpn7ILTkQUhPepWDwTN7hgf AxufcJX6gK90h1RBevEPiDUscn+AdlZoV56is= 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=S1vBKT0yWnLuB7U8YX8ngGZwmaPvDRzzZCxacO5i+2o=; b=LiJEK9UnXU+nDeN9BTzySOdXv9k9TuA/WbFAxZ+JxvtMrnK/SGJepXhZCv2+scG3LW RMrCwodTkf8HQicvZ9VjWcff5xLPECVfMyu9uzdGzuyQ6pIVsAPUr9FjXQCEn2P6k+DA Vdh1YccXdz/akrcOH15aQE3KCRxSgsahRIzbBXoDL0i8Cv7MpjTjDatJhmb8A9PBChiG 2o9/QbMdKPgHmn83QdPtzDSP6tGNn+MzwfaXiVUrZv622zU23eIaQWcIOAi1ImEk25aB 72/aafSwl8k1E0XnM6Yoc4JZZcdUpkM13NfJ6kRUuC1tCuzKWQENs50TbqSJCOlaz2gr Dq7w== X-Gm-Message-State: AOAM533bqx9ugn5W2vf1B03kZZIqUSXs+DhtWCB7WL2yoFjU9O5ZU4XG er0spB1IFPD0ykGXXVtyA3i2zQ== X-Received: by 2002:a17:902:40a:: with SMTP id 10mr180863ple.52.1591735322434; Tue, 09 Jun 2020 13:42:02 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id u17sm9394329pgo.90.2020.06.09.13.42.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 13:42:01 -0700 (PDT) Date: Tue, 9 Jun 2020 13:42:00 -0700 From: Kees Cook To: Kristen Carlson Accardi Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, "H. Peter Anvin" , Jessica Yu , arjan@linux.intel.com, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, rick.p.edgecombe@intel.com, Ard Biesheuvel , Tony Luck Subject: Re: [PATCH v2 9/9] module: Reorder functions Message-ID: <202006091331.A94BB0DA@keescook> References: <20200521165641.15940-1-kristen@linux.intel.com> <20200521165641.15940-10-kristen@linux.intel.com> <202005211415.5A1ECC638@keescook> <9fdea0bc0008eccd6dfcad496b37930cf5bd364a.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fdea0bc0008eccd6dfcad496b37930cf5bd364a.camel@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 09, 2020 at 01:14:04PM -0700, Kristen Carlson Accardi wrote: > On Thu, 2020-05-21 at 14:33 -0700, Kees Cook wrote: > > Oh! And I am reminded suddenly about CONFIG_FG_KASLR needing to > > interact > > correctly with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION in that we do NOT > > want the sections to be collapsed at link time: > > sorry - I'm a little confused and was wondering if you could clarify > something. Does this mean you expect CONFIG_FG_KASLR=y and > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y to be a valid config? I am not Yes, I don't see a reason they can't be used together. > familiar with the option, but it seems like you are saying that it > requires sections to be collapsed, in which case both of these options > as yes would not be allowed? Should I actively prevent this in the > Kconfig? No, I'm saying that CONFIG_LD_DEAD_CODE_DATA_ELIMINATION does _not_ actually require that the sections be collapsed, but the Makefile currently does this just to keep the resulting ELF "tidy". We want that disabled (for the .text parts) in the case of CONFIG_FG_KASLR. The dead code elimination step, is, IIUC, done at link time before the output sections are written. -- Kees Cook