From patchwork Thu Jun 7 14:35:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yu-cheng Yu X-Patchwork-Id: 10452249 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 008DF60146 for ; Thu, 7 Jun 2018 14:40:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DD9DD2955B for ; Thu, 7 Jun 2018 14:40:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DAE6229584; Thu, 7 Jun 2018 14:40:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B854329501 for ; Thu, 7 Jun 2018 14:40:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A56B36B0006; Thu, 7 Jun 2018 10:40:01 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 5221F6B0266; Thu, 7 Jun 2018 10:40:01 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DB2D6B0006; Thu, 7 Jun 2018 10:40:01 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id DA05C6B000A for ; Thu, 7 Jun 2018 10:40:00 -0400 (EDT) Received: by mail-pg0-f70.google.com with SMTP id w1-v6so3577075pgr.7 for ; Thu, 07 Jun 2018 07:40:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id:in-reply-to:references; bh=c3/GzKArSyLnziQQfhzwn+zCM13g2JUaSmB032/zXyY=; b=id4+CjIY/UOi4i33pQ9x98Rp6wP/T1UxqtLsw9Qjz0vZxwAG+X3Wt5Trkxv3bj7ut8 SG6FQgYXoJ6RiQyV0RQYMpL02R5Qa35rHbnryexlU6atDz0tfD4oS0retBsyyhpDTGZj Om1blgFzz4M5fjnx9FQBiD06EiO5p6T1p4Tob6LvOYrmGjo8W+0JxUG4dqSA2wQSSp+P P26o6aamapXjxIiLwCuY04HAMDzZ4d0Xh4FDclQb/VhBE62LKiFAStZx5wnX1da5FweQ VkWSDlWlIqakfzoNVgEDFEvCMI1BScfYPfqxO1MZXVm/qSwAycM8lekNOhJWpkmyvpo0 QbEA== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of yu-cheng.yu@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=yu-cheng.yu@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Gm-Message-State: APt69E2sv6UOhiEH+Jzs+9I/ny4o10pypzUrxTVqJvPvgR5FIhXDmrgm Azw5juj4pUkZzdIAzfGKpU/b/0E67p5cIoDZfqVvkMxYOH1e9iDC2Ys+VUpRW3iWMQoyQrzbpzF 0jAdnuMKsRndnlQM2rXHIiMjGHXSjLXOcP5Ea21Kbzq6ZX0xkwIjJ0uwGdOIpY1+1gg== X-Received: by 2002:a17:902:b48f:: with SMTP id y15-v6mr2339507plr.261.1528382400548; Thu, 07 Jun 2018 07:40:00 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIKYyl1/jgdal+F1Bvc1VHrCFAbdQ1qrDmQqLFAVD3W8KCzH79t4u3VFL4SfOUBbHfr7ZR4 X-Received: by 2002:a17:902:b48f:: with SMTP id y15-v6mr2339444plr.261.1528382399545; Thu, 07 Jun 2018 07:39:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528382399; cv=none; d=google.com; s=arc-20160816; b=TOLcsB4fH7XSEMyIobTFzNXCITRlqfos3AwwPiy1EjWoVybAo6VivogV0UcH1G2KDc LhOnDMhcNA5dsvA5egTTVodj88A98KJq7thMMiuOXCmhmoBJDBVQqAs2CJ5gOR3Mj1d/ afiZpzj3b68UeGM1qBBDbQJBlkVPAx/IB9CVPIZhsYYdcwJOPDbOBd5Gq2uVjMML8a0J hIzBZ07jEzol1DZskUCdhgxgxJr/6HovFRQT65w+Ki9JKUSVucSTIIwvHJ65NMCoHFWo Ml7E/bzyxpsrs5wNmUzcmZuvU59HfJdR2tDEtj1qPxxSN8iDHnlHEzWu4RYDfLK+g+6B BRjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=c3/GzKArSyLnziQQfhzwn+zCM13g2JUaSmB032/zXyY=; b=RX8Hmyl6MGnD5ili9twJW1ITzswZddtFaBXpaPXHHI9ae51HrFNikd0gKttL52wMa1 YDhynK2PYx4UEVKJaj1sm1vdI55uu9JscANRS5+isWW2KRIqEMwfpy1u2d6e1aiLZLoL SiP506HcNnQot2Izr097JsOtcsdiwOW5huFMj08a1tIkgw3tev20GUd6PzDgPFEuhpRs 6WdcwfSs7w6Y4bejOe3CxB47hEfZHcqNCOekFhLKA4cz9ssWIbErSYobXaLK2f2WL3sJ 06Hr6Hx084mlc5apnfjjS3fR8H0pavbvAm9Gshl9XXZJgRrFZasaX60l9WYzRxN5Dhl/ wTJw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of yu-cheng.yu@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=yu-cheng.yu@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from mga02.intel.com (mga02.intel.com. [134.134.136.20]) by mx.google.com with ESMTPS id 88-v6si53306702pla.315.2018.06.07.07.39.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 07:39:59 -0700 (PDT) Received-SPF: pass (google.com: domain of yu-cheng.yu@intel.com designates 134.134.136.20 as permitted sender) client-ip=134.134.136.20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of yu-cheng.yu@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=yu-cheng.yu@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2018 07:39:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,486,1520924400"; d="scan'208";a="54825999" Received: from 2b52.sc.intel.com ([143.183.136.51]) by fmsmga002.fm.intel.com with ESMTP; 07 Jun 2018 07:39:58 -0700 From: Yu-cheng Yu To: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "H.J. Lu" , Vedvyas Shanbhogue , "Ravi V. Shankar" , Dave Hansen , Andy Lutomirski , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , Mike Kravetz Cc: Yu-cheng Yu Subject: [PATCH 5/5] Documentation/x86: Add CET description Date: Thu, 7 Jun 2018 07:35:44 -0700 Message-Id: <20180607143544.3477-6-yu-cheng.yu@intel.com> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20180607143544.3477-1-yu-cheng.yu@intel.com> References: <20180607143544.3477-1-yu-cheng.yu@intel.com> 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: X-Virus-Scanned: ClamAV using ClamSMTP Explain how CET works and the noshstk/noibt kernel parameters. Signed-off-by: Yu-cheng Yu --- Documentation/admin-guide/kernel-parameters.txt | 6 + Documentation/x86/intel_cet.txt | 161 ++++++++++++++++++++++++ 2 files changed, 167 insertions(+) create mode 100644 Documentation/x86/intel_cet.txt diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f2040d46f095..c9a94bec1519 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2649,6 +2649,12 @@ noexec=on: enable non-executable mappings (default) noexec=off: disable non-executable mappings + noibt [X86-64] Disable indirect branch tracking for user-mode + applications + + noshstk [X86-64] Disable shadow stack support for user-mode + applications + nosmap [X86] Disable SMAP (Supervisor Mode Access Prevention) even if it is supported by processor. diff --git a/Documentation/x86/intel_cet.txt b/Documentation/x86/intel_cet.txt new file mode 100644 index 000000000000..1b902a6c49f4 --- /dev/null +++ b/Documentation/x86/intel_cet.txt @@ -0,0 +1,161 @@ +----------------------------------------- +Control Flow Enforcement Technology (CET) +----------------------------------------- + +[1] Overview + +Control Flow Enforcement Technology (CET) provides protection against +return/jump-oriented programing (ROP) attacks. It can be implemented to +protect both the kernel and applications. In the first phase, only the +user-mode protection is implemented for the 64-bit kernel. Thirty-two bit +applications are supported under the compatibility mode. + +CET includes shadow stack (SHSTK) and indirect branch tracking (IBT) and +they are enabled from two kernel configuration options: + + INTEL_X86_SHADOW_STACK_USER, and + INTEL_X86_BRANCH_TRACKING_USER. + +There are two command-line options for disabling CET features: + + noshstk - disables shadow stack, and + noibt - disables indirect branch tracking. + +At run time, /proc/cpuinfo shows the availability of SHSTK and IBT. + +[2] Application Enabling + +The design of CET user-mode interface provides maximum overall coverage +and compatibility with existing applications. + +To verify the CET capability of an application, use the following command +and look for SHSTK/IBT in the NT_GNU_PROPERTY_TYPE_0 field: + + readelf -n + +CET features are opt-in by each application. To build a CET-capable +application, the following tools are needed: Binutils v2.30, GCC v8.1, +and GLIBC v2.29 (or later). + +If an application has CET capabilities, is statically linked, and the +kernel supports CET, it will run with CET enabled. If an application +needs any shared libraries, the loader checks all dependencies and enables +CET only when all requirements are met. Once an application starts with +CET enabled, the protection cannot be turned off until the next exec(). + +[3] CET system calls + +The following arch_prctl() system calls are added for CET: + +(3a) arch_prctl(ARCH_CET_STATUS, unsigned long *addr) + + Return CET feature status. + + The parameter 'addr' is a pointer to a user buffer. + On returning to the caller, the kernel fills the following + information: + + *addr = SHSTK/IBT status + *(addr + 1) = SHSTK/IBT default setting on exec() + *(addr + 2) = default SHSTK size on exec() + +(3b) arch_prctl(ARCH_CET_DISABLE, unsigned long features) + + Disable SHSTK and/or IBT specified in 'features'. Return -EPERM + if CET is locked out. + +(3c) arch_prctl(ARCH_CET_LOCK) + + Lock out CET features; disable turning off of SHSTK/IBT. + +(3d) arch_prctl(ARCH_CET_EXEC, unsigned long *addr) + + Control how CET features should be enabled upon exec() a new + image. + + The parameter 'addr' is a pointer to a user buffer. + + *addr = a bitmap indicating which features are being changed + *(addr + 1) = how CET should be enabled upon exec(). + 0: Check ELF header + 1: Always disable + 2: Always enable + *(addr + 2) = default SHSTK size on exec() + +(3e) arch_prctl(ARCH_CET_ALLOC_SHSTK, unsigned long *addr) + + Allocate a new SHSTK. + + The parameter 'addr' is a pointer to a user buffer and indicates + the desired SHSTK size to allocate. On returning to the caller + the buffer contains the address of the new SHSTK. + +(3f) arch_prctl(ARCH_CET_PUSH_SHSTK, unsigned long *addr) + + Push a value onto the SHSTK. + + The parameter 'addr' is a pointer to a user buffer. + + *addr = the SHSTK pointer + *(addr + 1) = the value to push (a function return address) + +Note: ARCH_CET_ALLOC_SHSTK and ARCH_CET_PUSH_SHSTK are intended for + the implementation of GLIBC getcontext(), setcontext(), + makecontext(), and swapcontext(). + +(3g) arch_prctl(ARCH_CET_LEGACY_BITMAP, unsigned long *addr) + + If the current task does not have a legacy bitmap, setup one. + Return bitmap information as the following: + + *addr = bitmap base address + *(addr + 1) = bitmap size + +[4] The implementation of the SHSTK + +A task's SHSTK is allocated from memory to a fixed size that can +support 32 KB nested function calls; that is 256 KB for a 64-bit +application and 128 KB for a 32-bit application. The system admin +can change the size with the CET command line utility. + +The main program and its signal handlers use the same shadow stack. + +The SHSTK's vma has VM_SHSTK flag set; its PTEs are required to be +read-only and dirty. When a SHSTK PTE is not present, RO, and dirty, +a SHSTK access triggers a page fault with an additional SHSTK bit set +in the page fault error code. + +When a task forks a child, its SHSTK PTEs are copied and both the +parent's and the child's SHSTK PTEs are cleared of the dirty bit. +Upon the next SHSTK access, the resulting SHSTK page fault is handled +by page copy/re-use. + +When a pthread child is created, a separate SHSTK is created for the +child. + +[5] The management of read-only & dirty PTEs for SHSTK + +A RO and dirty PTE exists in the following cases: + +(5a) A page is modified and then shared with a fork()'ed child; +(5b) access_remote_vm with (FOLL_WRITE | FOLL_FORCE) on a RO page; +(5c) A SHSTK page. + +The processor does not read the dirty bit for (5a) and (5b), but +checks the dirty bit for (5c). To prevent accidental use of non- +SHSTK memory as SHSTK, we introduce the use of a spare bit of the +64-bit PTE as _PAGE_BIT_DIRTY_SW and exchange it with the dirty +bit for (5a) and (5b). This results to the following possible +PTE settings: + +Modified PTE: (R/W + DIRTY_HW) +Modified and shared PTE: (R/O + DIRTY_SW) +R/O PTE was (FOLL_FORCE | FOLL_WRITE): (R/O + DIRTY_SW) +SHSTK stack PTE: (R/O + DIRTY_HW) +Shared SHSTK PTE: (R/O + DIRTY_SW) + +[6] The implementation of IBT + +The kernel provides IBT support in mmap() of the legacy code bit map. +However, the management of the bitmap is done in the GLIBC or the +application.