Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp167578ybv; Tue, 18 Feb 2020 20:22:29 -0800 (PST) X-Google-Smtp-Source: APXvYqzZZV7nWao5rr4+YcGOwMAXM61TxxQzlAH1pXnqHFCETZbwqoZeHwvWL3ZaP9m4/dysljSf X-Received: by 2002:aca:3017:: with SMTP id w23mr3316738oiw.152.1582086149670; Tue, 18 Feb 2020 20:22:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582086149; cv=none; d=google.com; s=arc-20160816; b=1LTl9aC/z+aLZfLlRlopr8+2bmOMzpEftcpH8cS+QVWtXHt0x9V+fW5amTf13qHX2S zEp2z2klciAGznoIq2OI7o/q0tHOcJnkLSF6pHYMrylN4rju9FvCYVKLEV572qoYEAIN cDf7xigTbNlRJPI+L9LfEPMf+5PNkdUhK52PA1+GGfPKsjan0E/pEHRKA09G69lVxx5f DTtT4TslaSolqMPdFjHgn4njbfcH4LBqvRFEfPQME9EZH58INsbo2a2cKY1pRnO4Jrq0 jEi4S0/S/s03+5gs5tlxBbWX+JeAylZYkL8mfDMzIVDKvy3UOfKMJiCB3kAu9EzjyiXD Olsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=w1v42JIbxbTQaj+IwxBJakhg/k+j4nNZQJZ/BeGoer0=; b=0tOZh9Kebxp3YfymiSI6otWQgoosRM2B7m2XBSyVToc+b969xjQmWDtz1it543rgNA jgaAG++TdkuY20YJyFFFwFmDvU/f/nKgjjWJ6S+6GN/ZAoMR6qVla9cQkcLcFXj876B0 4VZmU7Qc/VDiCpxhWLqyFCF4WHDWGhHablQRt0yAZAQZhO8rY0enm0UGpe9/jr2Kxp4M EZ2mzi4naFA9ptBnNSxeErMRu0y4mcqBm0nNneTmoj/dVAsQHoIcel94t2bgDhKmZKrs mFSdgkl5kAUxI23cg0kYwc+gjMGEmi0I0ul8N2PtbE7QVpI1MgF87zxVzC2Uw0lk1h1V GUbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=MTrRstBO; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a92si477266otc.294.2020.02.18.20.22.07; Tue, 18 Feb 2020 20:22:29 -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=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=MTrRstBO; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726512AbgBSEUC (ORCPT + 99 others); Tue, 18 Feb 2020 23:20:02 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:40186 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726477AbgBSEUC (ORCPT ); Tue, 18 Feb 2020 23:20:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=w1v42JIbxbTQaj+IwxBJakhg/k+j4nNZQJZ/BeGoer0=; b=MTrRstBOnZxCNBLpVqArac2zI8 ZRetyXVcg2qmFGkwhf9hvQWNslqjh/oAAitsy1+jMz53ikunqAwVlwMaeK7TcENEcJIYL/l0QGCu/ 6ev7PfkAFxCp2mWpw+t5vQUez2oMrhh1H48QMRf0Izn7mrv4NsxRSZydBhENC5MBgcjyB09N+twpr ZSZBaVElmIt4rCHc+D97/8V7RvU2aD5qvXjVm2aNwmda0HqwSVTZpRsU/20Z6xVP7fx3nhgJ7BfNZ 6K4uCdk7Op/UDWyhUlRMFMxfC2kUkb/+ou7Sg4o1Fg+/bUmrNjML9RkRUmykXGkaG7AvFe1ss+rHL AI/pl1xA==; Received: from [2601:1c0:6280:3f0::19c2] by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1j4Gq7-0003eb-PE; Wed, 19 Feb 2020 04:19:59 +0000 Subject: Re: [PATCH v8 01/12] add support for Clang's Shadow Call Stack (SCS) To: Sami Tolvanen , Will Deacon , Catalin Marinas , Steven Rostedt , Masami Hiramatsu , Ard Biesheuvel , Mark Rutland , james.morse@arm.com Cc: Dave Martin , Kees Cook , Laura Abbott , Marc Zyngier , Nick Desaulniers , Jann Horn , Miguel Ojeda , Masahiro Yamada , clang-built-linux@googlegroups.com, kernel-hardening@lists.openwall.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20191018161033.261971-1-samitolvanen@google.com> <20200219000817.195049-1-samitolvanen@google.com> <20200219000817.195049-2-samitolvanen@google.com> From: Randy Dunlap Message-ID: <60ec3a49-7b71-df31-f231-b48ff135b718@infradead.org> Date: Tue, 18 Feb 2020 20:19:56 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200219000817.195049-2-samitolvanen@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sami, a couple of minor tweaks: On 2/18/20 4:08 PM, Sami Tolvanen wrote: > diff --git a/arch/Kconfig b/arch/Kconfig > index 98de654b79b3..66b34fd0df54 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -526,6 +526,40 @@ config STACKPROTECTOR_STRONG > about 20% of all kernel functions, which increases the kernel code > size by about 2%. > > +config ARCH_SUPPORTS_SHADOW_CALL_STACK > + bool > + help > + An architecture should select this if it supports Clang's Shadow > + Call Stack, has asm/scs.h, and implements runtime support for shadow > + stack switching. > + > +config SHADOW_CALL_STACK > + bool "Clang Shadow Call Stack" > + depends on ARCH_SUPPORTS_SHADOW_CALL_STACK > + help > + This option enables Clang's Shadow Call Stack, which uses a > + shadow stack to protect function return addresses from being > + overwritten by an attacker. More information can be found from found in > + Clang's documentation: > + > + https://clang.llvm.org/docs/ShadowCallStack.html > + > + Note that security guarantees in the kernel differ from the ones > + documented for user space. The kernel must store addresses of shadow > + stacks used by other tasks and interrupt handlers in memory, which > + means an attacker capable reading and writing arbitrary memory may capable of > + be able to locate them and hijack control flow by modifying shadow > + stacks that are not currently in use. > + > +config SHADOW_CALL_STACK_VMAP > + bool "Use virtually mapped shadow call stacks" > + depends on SHADOW_CALL_STACK > + help > + Use virtually mapped shadow call stacks. Selecting this option > + provides better stack exhaustion protection, but increases per-thread > + memory consumption as a full page is allocated for each shadow stack. > + > + > config HAVE_ARCH_WITHIN_STACK_FRAMES > bool > help thanks. -- ~Randy