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=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 82291C10F27 for ; Mon, 9 Mar 2020 17:01:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3EF1820727 for ; Mon, 9 Mar 2020 17:01:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3EF1820727 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D0E016B0005; Mon, 9 Mar 2020 13:01:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CBDDB6B0006; Mon, 9 Mar 2020 13:01:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5E276B0007; Mon, 9 Mar 2020 13:01:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 97D966B0005 for ; Mon, 9 Mar 2020 13:01:13 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 61F0B180AD81A for ; Mon, 9 Mar 2020 17:01:13 +0000 (UTC) X-FDA: 76576439226.12.sock40_27ac2036a2745 X-HE-Tag: sock40_27ac2036a2745 X-Filterd-Recvd-Size: 7733 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 17:01:12 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2020 10:00:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,534,1574150400"; d="scan'208";a="230995194" Received: from yyu32-desk.sc.intel.com ([143.183.136.146]) by orsmga007.jf.intel.com with ESMTP; 09 Mar 2020 10:00:56 -0700 Message-ID: <0f43463e02d1be2af6bcf8ff6917e751ba7676a0.camel@intel.com> Subject: Re: [RFC PATCH v9 01/27] Documentation/x86: Add CET description From: Yu-cheng Yu To: Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , x86-patch-review@intel.com Date: Mon, 09 Mar 2020 10:00:56 -0700 In-Reply-To: <9ae1cf84-1d84-1d34-c0ce-48b0d70b8f3f@intel.com> References: <20200205181935.3712-1-yu-cheng.yu@intel.com> <20200205181935.3712-2-yu-cheng.yu@intel.com> <9ae1cf84-1d84-1d34-c0ce-48b0d70b8f3f@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Wed, 2020-02-26 at 09:57 -0800, Dave Hansen wrote: > > index ade4e6ec23e0..8b69ebf0baed 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -3001,6 +3001,12 @@ > > noexec=on: enable non-executable mappings (default) > > noexec=off: disable non-executable mappings > > > > + no_cet_shstk [X86-64] Disable Shadow Stack for user-mode > > + applications > > If we ever add kernel support, "no_cet_shstk" will mean "no cet shstk > for userspace"? What about no_user_shstk, no_kernel_shstk? > > > + no_cet_ibt [X86-64] Disable Indirect Branch Tracking for user-mode > > + applications > > + > > nosmap [X86,PPC] > > Disable SMAP (Supervisor Mode Access Prevention) > > even if it is supported by processor. > > BTW, this documentation is misplaced. It needs to go to the spot where > you introduce the code for these options. We used to introduce the document later in the series. The feedback was to introduce it first so that readers know what to expect. [...] > > diff --git a/Documentation/x86/intel_cet.rst b/Documentation/x86/intel_cet.rst > > new file mode 100644 > > index 000000000000..71e2462fea5c > > --- /dev/null > > +++ b/Documentation/x86/intel_cet.rst > > @@ -0,0 +1,294 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +========================================= > > +Control-flow Enforcement Technology (CET) > > +========================================= > > + > > +[1] Overview > > +============ > > + > > +Control-flow Enforcement Technology (CET) provides protection against > > +return/jump-oriented programming (ROP) attacks. It can be setup to [...] > > + > > +There are two kernel configuration options: > > + > > + X86_INTEL_SHADOW_STACK_USER, and > > + X86_INTEL_BRANCH_TRACKING_USER. > > + > > +To build a CET-enabled kernel, Binutils v2.31 and GCC v8.1 or later > > +are required. > > Why are these needed to build a CET-enabled kernel? We could (and used to) allow legacy toolchains, but after considering practical purposes, dropped the support. We can continue the discussion, and if those are desired, bring them back. [...] > > +[2] CET assembly instructions > > +============================= > > Why do we need this in the kernel? What is specific to Linux or the > kernel? Why wouldn't I just go read the SDM if I want to know how the > instructions work? Now the SDM has this. I will drop this section. > > +[3] Application Enabling > > +======================== > > + > > +An application's CET capability is marked in its ELF header and can > > +be verified from the following command output, in the > > +NT_GNU_PROPERTY_TYPE_0 field: > > + > > + readelf -n > > + > > +If an application supports CET and is statically linked, it will run > > +with CET protection. If the application needs any shared libraries, > > +the loader checks all dependencies and enables CET only when all > > +requirements are met. > > What about shared libraries loaded after the program starts? The loader does the check for dlopen(). > > +[4] Legacy Libraries > > +==================== > > + > > +GLIBC provides a few tunables for backward compatibility. > > + > > +GLIBC_TUNABLES=glibc.tune.hwcaps=-SHSTK,-IBT > > + Turn off SHSTK/IBT for the current shell. > > + > > +GLIBC_TUNABLES=glibc.tune.x86_shstk= > > + This controls how dlopen() handles SHSTK legacy libraries:: > > + > > + on - continue with SHSTK enabled; > > + permissive - continue with SHSTK off. > > This seems like manpage fodder more than kernel documentation to me. Yes, we can drop this as well. [...] > > +Note: > > + There is no CET-enabling arch_prctl function. By design, CET is > > + enabled automatically if the binary and the system can support it. > > This is kinda interesting. It means that a JIT couldn't choose to > protect the code it generates and have different rules from itself? JIT needs to be updated for CET first. Once that is done, it runs with CET enabled. It can use the NOTRACK prefix, for example. > > + The parameters passed are always unsigned 64-bit. When an IA32 > > + application passing pointers, it should only use the lower 32 bits. > > Won't a 32-bit app calling prctl() use the 32-bit ABI? How would it > even know it's running on a 64-bit kernel? The 32-bit app is passing only a pointer to an array of 64-bit numbers. > > > +[6] The implementation of the SHSTK > > +=================================== > > + > > +SHSTK size > > +---------- > > + > > +A task's SHSTK is allocated from memory to a fixed size of > > +RLIMIT_STACK. > > I can't really parse that sentence. Is this saying that shadow stacks > are limited by and share space with normal stacks via RLIMIT_STACK? > > > A compat-mode thread's SHSTK size is 1/4 of > > +RLIMIT_STACK. The smaller 32-bit thread SHSTK allows more threads to > > +share a 32-bit address space. > > I thought the size was passed in from userspace? Where does this sizing > take place? Is this a convention or is it being enforced? I will make this (and other things you pointed out) clear in the next version. Yu-cheng