Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1517440ybv; Thu, 6 Feb 2020 05:33:50 -0800 (PST) X-Google-Smtp-Source: APXvYqyVH0o7y4ffo1aBSyQftgp0O5kKUQIIybLGH7HZqdBX/nZcih3TtZsEtflNFMrpGrTq+IYT X-Received: by 2002:a05:6830:124b:: with SMTP id s11mr29591365otp.333.1580996030262; Thu, 06 Feb 2020 05:33:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580996030; cv=none; d=google.com; s=arc-20160816; b=c3t9sy1Okm4x6wE4q2NJVEP0RIN9PkM+qMKBCpqrX7t0hhFZPx1ZtmoUvOonlV/9sV /rK01P4zKZHS0ga+pyEirr9xhFoWnv9ZULHwtjH5+zuyU5fXGdD0c7zOsv6K19JIh5Sw EJSEuOZy4MIpwUgNSyOIB5P51TKsW3itC/C6TehOMBKf3SQhrwGmYOIf2CF5LZw9YpM7 FmJ9Nv+HAntjMIBXpjJTD5m/ciqgGGFLEtWfO9rvlTmi5pc1FrReLOXL/M5HyMtyj0aN dQwAk+K5E5Ddagj42aqp6iMylBR+Px8+f8t14OKMR2r2TK8rDzV5Bv8pW0zUMHpnl7zq ktfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ryGvaK7IdgWsNv1S2gpyspjnVMkTkjmubI6kwmTSrLk=; b=ClGMBkymHJgouO3DeczM27KBOSB4FY6N7Hti3WLjjZh9yLpwgPS50dYG430e9SC+tC KYcvjm7UXYLOAxmymD8sAoR6mfFa3k6hwTlhprlCvY/dm8tVMZdhaqSRtY6eEwD6vuia XsiNzoQL32VYHyODWmCgryvvaNPzMyU8xcqUk4nFBo0p9P/NJjazv7Z1VSrrL51sDTd+ OjTUNPAkFiockrM78tTVmecrPRqamxzPOjhF/Ia2GPnSoWi4uyAM2jI09PqzPohm89uk uuDazlFMXO1AoCdhzkeWjcOtGmxAa8YWrt3zYDVusjnMGISKN49W+kNmqo38LiBa1GyA GHhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kDzqXbH0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k15si1963538oik.130.2020.02.06.05.33.37; Thu, 06 Feb 2020 05:33:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kDzqXbH0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727566AbgBFNP7 (ORCPT + 99 others); Thu, 6 Feb 2020 08:15:59 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:34997 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726538AbgBFNP7 (ORCPT ); Thu, 6 Feb 2020 08:15:59 -0500 Received: by mail-ot1-f67.google.com with SMTP id r16so5434745otd.2 for ; Thu, 06 Feb 2020 05:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ryGvaK7IdgWsNv1S2gpyspjnVMkTkjmubI6kwmTSrLk=; b=kDzqXbH0tYyEVf99zGl3eoyT6Nsn3nOP8W6PodjYpnd2lyosP0ffMCaLysyucPg8WL NN6N35Vag2viteeA/AWqyhf/PYw3nnCzF9oXjfBolLOFRGh3VhjPkJGHedpBfRH1CB0x OMKuv485yF9gCbiTuzJTDbBslBU9kMW61A9NzNf1j0O1ZoGNIU3ZrbzWdJzgmP/Ao6WR Q4B4m1YsesZjytlcnLa4JW4O8pEggwZK1uyzVmHIuL5fXTOlMj3N+dUV+8C5s7seau0C OkC/0A6TE7Qx8SBM8pYi3ovQO9+3mJqMsXz7kNZnDvZt2k7GlHFdZeWx3vWtVKrHi1/e 1u/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ryGvaK7IdgWsNv1S2gpyspjnVMkTkjmubI6kwmTSrLk=; b=VT4NXRk6w8cAZ45ySem+X4oTW0VbJ3glLsJlxYkuOXBBCfWlCEtEiwSZlQAM40rk/H M5IO7B3u5wUQZa3ELKDw90ldfbzPnyziq688tnbVEG0DmYXnSUr2QUkbA6EHvtXasOqu M49HR/yN9Gzx+pCD2h7GEqjbo6gonoTc7hzfNzt9EHyssOJDDQDsg+6oeHhSxCT9z1tB UiAtQk7YuLVcvdbI/oDFFARU6UnnLymjTV2MTPzZIk4v6d115qa99bd5jH4DHlT6jE5b EubYPowF6hsX7gNg62nFMw8nylqml/GzoYB6AdCo+Iw1moel4ulNFSxSL1tkPucWfy+r uhIQ== X-Gm-Message-State: APjAAAXjSzeU1GXktDuc2pT6ST4IP7fXfPFn4RRSlbj1t206duRl/4V5 eFD461ApTRjLVSuQ1ZP5tvPAG05Sx4PD8s02iIoCuA== X-Received: by 2002:a9d:74d0:: with SMTP id a16mr18723352otl.228.1580994956896; Thu, 06 Feb 2020 05:15:56 -0800 (PST) MIME-Version: 1.0 References: <20200205223950.1212394-1-kristen@linux.intel.com> <20200205223950.1212394-7-kristen@linux.intel.com> <202002060408.84005CEFFD@keescook> In-Reply-To: <202002060408.84005CEFFD@keescook> From: Jann Horn Date: Thu, 6 Feb 2020 14:15:30 +0100 Message-ID: Subject: Re: [RFC PATCH 06/11] x86: make sure _etext includes function sections To: Kees Cook Cc: Kristen Carlson Accardi , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Arjan van de Ven , Rick Edgecombe , "the arch/x86 maintainers" , kernel list , Kernel Hardening Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 6, 2020 at 1:26 PM Kees Cook wrote: > I know x86_64 stack alignment is 16 bytes. That's true for the standard sysv ABI that is used in userspace; but the kernel uses a custom ABI with 8-byte stack alignment. See arch/x86/Makefile: # For gcc stack alignment is specified with -mpreferred-stack-boundary, # clang has the option -mstack-alignment for that purpose. ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) cc_stack_align4 := -mpreferred-stack-boundary=2 cc_stack_align8 := -mpreferred-stack-boundary=3 else ifneq ($(call cc-option, -mstack-alignment=16),) cc_stack_align4 := -mstack-alignment=4 cc_stack_align8 := -mstack-alignment=8 endif [...] # By default gcc and clang use a stack alignment of 16 bytes for x86. # However the standard kernel entry on x86-64 leaves the stack on an # 8-byte boundary. If the compiler isn't informed about the actual # alignment it will generate extra alignment instructions for the # default alignment which keep the stack *mis*aligned. # Furthermore an alignment to the register width reduces stack usage # and the number of alignment instructions. KBUILD_CFLAGS += $(call cc-option,$(cc_stack_align8)) > I cannot find evidence for > what function start alignment should be. There is no architecturally required alignment for functions, but Intel's Optimization Manual () recommends in section 3.4.1.5, "Code Alignment": | Assembly/Compiler Coding Rule 12. (M impact, H generality) | All branch targets should be 16-byte aligned. AFAIK this is recommended because, as documented in section 2.3.2.1, "Legacy Decode Pipeline" (describing the frontend of Sandy Bridge, and used as the base for newer microarchitectures): | An instruction fetch is a 16-byte aligned lookup through the ITLB and into the instruction cache. | The instruction cache can deliver every cycle 16 bytes to the instruction pre-decoder. AFAIK this means that if a branch ends close to the end of a 16-byte block, the frontend is less efficient because it may have to run two instruction fetches before the first instruction can even be decoded.