Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp389501imm; Thu, 7 Jun 2018 21:23:18 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJN4NW1a+N+PCcsXBY0fgxfzs/lWDvbUbhVNXn23MK/+gPF+SFsp1wI5IHQMbiCNh5lTt4W X-Received: by 2002:a17:902:8ec2:: with SMTP id x2-v6mr4791784plo.370.1528431798527; Thu, 07 Jun 2018 21:23:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528431798; cv=none; d=google.com; s=arc-20160816; b=1CVFCd63+BZ2RFBVJCnhPdyeweGJqiLGsMeBcC+ODJhoDZVIYoTwlMhe7ESg0Oe/uL bKjBe7bKhYqWsm/CyMh8xus+lRPRCvTyNQoRxbBbT9ITpiPDY4UUAXhSY71lEQMyXCuF lzS65e2Hog2vn4plyqV1oER1APAQGHoMxB6xZjFCZqfs0LLII68KRX232ccXElkYoKq5 kTcp0dvgE+gWA1IO09eRYY892eNnqGqaTDIVVQC0NIZ+/S2YG9FFw5g0wHCQV2/npa2l hxrmaIr5IU3J5wI0kDOvnbP7ZTiWRQ/cvzdD681D1MPOqAfgo92UOUfwCmlQq9v+eDUJ ZNng== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=k5mD3v2tbRF39pHp31qH5+ZJN6X27TzDlTaHW4MA27E=; b=fJedcBxufQUe5XmlxFLGlMp5LLk3clF5CCIpL6A56dizVGy2LyGWFdo/INv/Bb/QnL svwl31nOvksLNbyPA0/GHqPqXJ0/MNZcrp6ir0TWWjRVQOfIhC54jtwlFYm4t04FXGHO tAW4GIPSDp4Kc+ewzyyIyEgyqmqUVWBuaxpZWLmJkxnqXngr3Tac0Wn4wZ7xqNuQX84V pg68amYfzQ3LA1hGUxRiCfjtj+A18d5KReBafXxV/T/PpFXbD93/oZ740nDuZXbfEBwP hKAW+fJLAIutrOpeJzDU+vFD856kisZCtUIqujMVO9yPzCRnBdA3PM5P1l/Y3C3xnB42 Xlqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=X8VxCiK0; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 30-v6si27482151plf.596.2018.06.07.21.23.04; Thu, 07 Jun 2018 21:23:18 -0700 (PDT) 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=@gmail.com header.s=20161025 header.b=X8VxCiK0; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751120AbeFHEWS (ORCPT + 99 others); Fri, 8 Jun 2018 00:22:18 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:39416 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750837AbeFHEWP (ORCPT ); Fri, 8 Jun 2018 00:22:15 -0400 Received: by mail-oi0-f66.google.com with SMTP id t22-v6so10676434oih.6; Thu, 07 Jun 2018 21:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k5mD3v2tbRF39pHp31qH5+ZJN6X27TzDlTaHW4MA27E=; b=X8VxCiK0wD710ngM4miuPE8oC7erX0+/auyhTud8wMhN08vHj0WKADV14OqqRWDN3x 4tQXfOMrqBzYEwrQqtf1gzEQzOjEcnDRxIDKTR4L4cPExOtLKIjblwa3NKSEUU5XuGck TgJoV6xMSNK/iqKr1LB2jTKEVIIspvanR5joP4taZEoXg4AUeU4dxrF8m1JqHh6YdVoC fzbVlKOCcK0zQ52bSzDg/sTmGVzP1N5rOKvnruBjhDMozEHzc+Gg9bcPSj7RPjOnPGTy guukJkaopUZ4a52wgD9oazhgUXrCDEeisMNVIVcDSNjq9/3prSJKy4BEPI2mHG+ssSPf eMFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k5mD3v2tbRF39pHp31qH5+ZJN6X27TzDlTaHW4MA27E=; b=DfJwI79xK8L0LRCsighaYyvc7EQtD12CVwk8+v493WxUfKkZSneHBksKgLo9xOcGWm sYzkuXl3qQjCI/SBdqzn5Wm1Ty3KnnGptDNT4LPXvUBzeZyHW+GykuqzPeuOnkfYeelq Nz+XutcTUVYJ6ZlGb8x+5dxbIff7RbS8cj2zK9vbKCzF6CmtWqFYT4P8KAEDJWfX/AUE kd4LgT0xFWekxGxHYQ+XnKpb5HYvGRQKnDW05z7K8iT8TK0hk5za11WhOWWE8cI3H9PD EHQobIYf3bLFoVjbcTTMD9XwmKSgKJL1hpC9tsG6tumo5B3ac2ngx1vyy/7fHbzbLjNn fOlA== X-Gm-Message-State: APt69E2b/fl5c0aeW8UUAmYLcIvsk5SkmXc6LiIowqjOHrY/0aiDUbHs a5SMLo/FrAItFvkrahgD62PVR3pmwNtdw1Ys9Jg= X-Received: by 2002:aca:df54:: with SMTP id w81-v6mr2544697oig.104.1528431734163; Thu, 07 Jun 2018 21:22:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:7019:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 21:22:13 -0700 (PDT) In-Reply-To: References: <20180607143807.3611-1-yu-cheng.yu@intel.com> <20180607143807.3611-7-yu-cheng.yu@intel.com> <1528403417.5265.35.camel@2b52.sc.intel.com> From: "H.J. Lu" Date: Thu, 7 Jun 2018 21:22:13 -0700 Message-ID: Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack To: Andy Lutomirski Cc: Yu-cheng Yu , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "Shanbhogue, Vedvyas" , "Ravi V. Shankar" , Dave Hansen , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com 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, Jun 7, 2018 at 3:02 PM, H.J. Lu wrote: > On Thu, Jun 7, 2018 at 2:01 PM, Andy Lutomirski wrote: >> On Thu, Jun 7, 2018 at 1:33 PM Yu-cheng Yu wrote: >>> >>> On Thu, 2018-06-07 at 11:48 -0700, Andy Lutomirski wrote: >>> > On Thu, Jun 7, 2018 at 7:41 AM Yu-cheng Yu wrote: >>> > > >>> > > The following operations are provided. >>> > > >>> > > ARCH_CET_STATUS: >>> > > return the current CET status >>> > > >>> > > ARCH_CET_DISABLE: >>> > > disable CET features >>> > > >>> > > ARCH_CET_LOCK: >>> > > lock out CET features >>> > > >>> > > ARCH_CET_EXEC: >>> > > set CET features for exec() >>> > > >>> > > ARCH_CET_ALLOC_SHSTK: >>> > > allocate a new shadow stack >>> > > >>> > > ARCH_CET_PUSH_SHSTK: >>> > > put a return address on shadow stack >>> > > >> And why do we need ARCH_CET_EXEC? >> >> For background, I really really dislike adding new state that persists >> across exec(). It's nice to get as close to a clean slate as possible >> after exec() so that programs can run in a predictable environment. >> exec() is also a security boundary, and anything a task can do to >> affect itself after exec() needs to have its security implications >> considered very carefully. (As a trivial example, you should not be >> able to use cetcmd ... sudo [malicious options here] to cause sudo to >> run with CET off and then try to exploit it via the malicious options. >> >> If a shutoff is needed for testing, how about teaching ld.so to parse >> LD_CET=no or similar and protect it the same way as LD_PRELOAD is >> protected. Or just do LD_PRELOAD=/lib/libdoesntsupportcet.so. >> > > I will take a look. We can use LD_CET to turn off CET. Since most of legacy binaries are compatible with shadow stack, ARCH_CET_EXEC can be used to turn on shadow stack on legacy binaries: [hjl@gnu-cet-1 glibc]$ readelf -n /bin/ls| head -10 Displaying notes found in: .note.ABI-tag Owner Data size Description GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag) OS: Linux, ABI: 3.2.0 Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA used: [hjl@gnu-cet-1 glibc]$ cetcmd --on -- /bin/ls / Segmentation fault [hjl@gnu-cet-1 glibc]$ cetcmd --on -f shstk -- /bin/ls / bin dev export lib libx32 media mnt opt root sbin sys usr boot etc home lib64 lost+found misc net proc run srv tmp var [hjl@gnu-cet-1 glibc]$ cetcmd --on -f ibt -- /bin/ls / Segmentation fault [hjl@gnu-cet-1 glibc]$ -- H.J.