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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 4D17BC433DF for ; Mon, 22 Jun 2020 21:42:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0CBBB2075A for ; Mon, 22 Jun 2020 21:42:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="r0DY4x7U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CBBB2075A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7CB826B0006; Mon, 22 Jun 2020 17:42:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77B0E6B0007; Mon, 22 Jun 2020 17:42:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6698D6B000C; Mon, 22 Jun 2020 17:42:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by kanga.kvack.org (Postfix) with ESMTP id 4966D6B0006 for ; Mon, 22 Jun 2020 17:42:58 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C8C72BF6A4 for ; Mon, 22 Jun 2020 21:42:57 +0000 (UTC) X-FDA: 76958173194.03.lake54_500e08026e36 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 9435C28A4EB for ; Mon, 22 Jun 2020 21:42:57 +0000 (UTC) X-HE-Tag: lake54_500e08026e36 X-Filterd-Recvd-Size: 6929 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2020 21:42:57 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id d21so8419863lfb.6 for ; Mon, 22 Jun 2020 14:42:56 -0700 (PDT) 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=hqlIISzIW03YTIn+IXU1UUFP1CW/3V82KQ6IEM7geR0=; b=r0DY4x7UzAHeQZoPjhdk2r7pUPSknDOTxdrF8KRA6OcukEX8mWdDnLdR3yjOmhmYne awFznm+XAuVdZ8nE7fsaNZTS1wAUeh7i57IpVG26eXFZkxYzszfpbgcx540TIfBtqUxz jWj0jxYPt5QA1TkKbSgVYMEmu9O3VtX8jX/MQX2RxhHfmX+1vSoKqkDhGmta17TKAE+W Tz9H/ZKMG20/IjU7PAhFoNhzdL6w+2gQjVYB2/IvVWij44sCiBqZ0hoplQQpqpk/pj2v AMJmLfDkaluen4kFMVCQ3DOYqq8mmJw9gJ/6V5SI15bUKMy8pTZRWR6BZUMmvhf/CzUc Mr9Q== 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=hqlIISzIW03YTIn+IXU1UUFP1CW/3V82KQ6IEM7geR0=; b=UoJUNYsKkMqqBkRC11TWJbegbNgg7mngfois8GG31mdzVsWGr0E6tdQueMi4wvR8g4 kLhx6d0qfofkTKVaBljgEr2V5nn9+sjsOebZL40eqWHbftFCrzRjk9PDehMNka5oDC1q 8TpAw5g9m39VQ0Y2fCYbYTAvIEZnM6lkocA1sFY4XhfLSC/mM4C7fXjrbYQJifk8lyc4 hGZdFqrQ/sZsAA6VmD/uSCGjqiCtZBytZjTGxckh0kLDGq2js5+Nr7YGzFh9pqOM80Jy 94NkxV4P/1Gun/wKt168us0Wp61Y8WOjqDeRbIED126n7JJpTCuxxPKapVG7FSy42EwN lJsg== X-Gm-Message-State: AOAM531tLTvoFcPRsCxTqhD/oXSUXPXVU2057BkExWVZGnZcYSYEm6YF jMLsrMysK2Ze18itp5rYPkpCzqgiOlrzaeJ2RVhIgw== X-Google-Smtp-Source: ABdhPJxLOcc9zOfFkNQLHUw25KEy+AUpLGEG1pTH0THPNaOezrQbLYNPLk7zcaTh0H/YpTzAa5EnWEvIE9AHELkuuu8= X-Received: by 2002:a19:8b8a:: with SMTP id n132mr10747294lfd.45.1592862175484; Mon, 22 Jun 2020 14:42:55 -0700 (PDT) MIME-Version: 1.0 References: <20200622193146.2985288-1-keescook@chromium.org> <20200622193146.2985288-4-keescook@chromium.org> <202006221426.CEEE0B8@keescook> In-Reply-To: <202006221426.CEEE0B8@keescook> From: Jann Horn Date: Mon, 22 Jun 2020 23:42:29 +0200 Message-ID: Subject: Re: [PATCH v4 3/5] stack: Optionally randomize kernel stack offset each syscall To: Kees Cook Cc: Thomas Gleixner , Elena Reshetova , "the arch/x86 maintainers" , Andy Lutomirski , Peter Zijlstra , Catalin Marinas , Will Deacon , Mark Rutland , Alexander Potapenko , Alexander Popov , Ard Biesheuvel , Kernel Hardening , Linux ARM , Linux-MM , kernel list Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9435C28A4EB X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jun 22, 2020 at 11:30 PM Kees Cook wrote: > On Mon, Jun 22, 2020 at 10:07:37PM +0200, Jann Horn wrote: > > On Mon, Jun 22, 2020 at 9:31 PM Kees Cook wrote: > > > This provides the ability for architectures to enable kernel stack base > > > address offset randomization. This feature is controlled by the boot > > > param "randomize_kstack_offset=on/off", with its default value set by > > > CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT. > > [...] > > > +#define add_random_kstack_offset() do { \ > > > + if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, \ > > > + &randomize_kstack_offset)) { \ > > > + u32 offset = this_cpu_read(kstack_offset); \ > > > + u8 *ptr = __builtin_alloca(offset & 0x3FF); \ > > > + asm volatile("" : "=m"(*ptr)); \ > > > + } \ > > > +} while (0) > > > > clang generates better code here if the mask is stack-aligned - > > otherwise it needs to round the stack pointer / the offset: [...] > > Maybe this should be something along the lines of > > __builtin_alloca(offset & (0x3ff & ARCH_STACK_ALIGN_MASK)) (with > > appropriate definitions of the stack alignment mask depending on the > > architecture's choice of stack alignment for kernel code). > > Is that explicitly selected anywhere in the kernel? I thought the > alignment was left up to the compiler (as in I've seen bugs fixed where > the kernel had to deal with the alignment choices the compiler was > making...) No, at least on x86-64 and x86 Linux overrides the normal ABI. From 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 [...] ifeq ($(CONFIG_X86_32),y) [...] # Align the stack to the register width instead of using the default # alignment of 16 bytes. This reduces stack usage and the number of # alignment instructions. KBUILD_CFLAGS += $(call cc-option,$(cc_stack_align4)) [...] else [...] # 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)) [...] endif Normal x86-64 ABI has 16-byte stack alignment; Linux kernel x86-64 ABI has 8-byte stack alignment. Similarly, the normal Linux 32-bit x86 ABI is 16-byte aligned; meanwhile Linux kernel x86 ABI has 4-byte stack alignment. This is because userspace code wants the stack to be sufficiently aligned for fancy SSE instructions and such; the kernel, on the other hand, never uses those in normal code, and cares about stack usage and such very much.