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=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 11EF7C2BBD1 for ; Mon, 14 Sep 2020 18:31:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 915CB217BA for ; Mon, 14 Sep 2020 18:31:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="D4P7AEng" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 915CB217BA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 145256B0062; Mon, 14 Sep 2020 14:31:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F6768E0003; Mon, 14 Sep 2020 14:31:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F26026B0074; Mon, 14 Sep 2020 14:31:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id DC9336B0062 for ; Mon, 14 Sep 2020 14:31:16 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 91AA88249980 for ; Mon, 14 Sep 2020 18:31:16 +0000 (UTC) X-FDA: 77262509352.24.brass92_0e0f25b2710a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 650131A4A5 for ; Mon, 14 Sep 2020 18:31:16 +0000 (UTC) X-HE-Tag: brass92_0e0f25b2710a X-Filterd-Recvd-Size: 5850 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Sep 2020 18:31:15 +0000 (UTC) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7355521BE5 for ; Mon, 14 Sep 2020 18:31:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600108274; bh=TWMzqZoZNralDEd5I14l94VOUCKWS0bUz/b6Q4OWmsg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=D4P7AEngB+S1f31yQcalYo1zCNFyveknGKD9Hj70JfD4ABuAiXlotcEedmXFm7ic5 hyF+FdjUZ/Pv8vmvFKWoUUv8UKd7aD5CEBujLlrbWQz6oxj49Y/+V5ZJ8vRVNdjlUU Hf9ohxCwkyBAIRMBxwyvi8S9wNjMHJEHhe3JffZo= Received: by mail-wr1-f54.google.com with SMTP id k15so656481wrn.10 for ; Mon, 14 Sep 2020 11:31:14 -0700 (PDT) X-Gm-Message-State: AOAM53016yprF95IAfYh6EQR4hbNJKZsUBABgbJdhHXnQTs3fkdobDXU CVHmIBIFCRhhwe0jezJK80O72Hyhs0hAN0FtGUIwxg== X-Google-Smtp-Source: ABdhPJzMOb3y0FnJul9OcJh57QbJ0oJTgC7Zp8nhwEEKBKBm7cEIBddAZgePqa+NXgC52VXRnjm9D5o/WjTt/jkVxNo= X-Received: by 2002:a5d:5111:: with SMTP id s17mr17179124wrt.70.1600108272961; Mon, 14 Sep 2020 11:31:12 -0700 (PDT) MIME-Version: 1.0 References: <086c73d8-9b06-f074-e315-9964eb666db9@intel.com> <0e9996bc-4c1b-cc99-9616-c721b546f857@intel.com> <4f2dfefc-b55e-bf73-f254-7d95f9c67e5c@intel.com> <20200901102758.GY6642@arm.com> <32005d57-e51a-7c7f-4e86-612c2ff067f3@intel.com> <46dffdfd-92f8-0f05-6164-945f217b0958@intel.com> <6e1e22a5-1b7f-2783-351e-c8ed2d4893b8@intel.com> <5979c58d-a6e3-d14d-df92-72cdeb97298d@intel.com> <08c91835-8486-9da5-a7d1-75e716fc5d36@intel.com> <41aa5e8f-ad88-2934-6d10-6a78fcbe019b@intel.com> In-Reply-To: <41aa5e8f-ad88-2934-6d10-6a78fcbe019b@intel.com> From: Andy Lutomirski Date: Mon, 14 Sep 2020 11:31:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack To: Dave Hansen Cc: Yu-cheng Yu , Andy Lutomirski , Dave Martin , "H.J. Lu" , Florian Weimer , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Weijiang Yang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 650131A4A5 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Sep 14, 2020, at 7:50 AM, Dave Hansen wrote: > > =EF=BB=BFOn 9/11/20 3:59 PM, Yu-cheng Yu wrote: > ... >> Here are the changes if we take the mprotect(PROT_SHSTK) approach. >> Any comments/suggestions? > > I still don't like it. :) > > I'll also be much happier when there's a proper changelog to accompany > this which also spells out the alternatives any why they suck so much. > Let=E2=80=99s take a step back here. Ignoring the precise API, what exactly= is a shadow stack from the perspective of a Linux user program? The simplest answer is that it=E2=80=99s just memory that happens to have certain protections. This enables all kinds of shenanigans. A program could map a memfd twice, once as shadow stack and once as non-shadow-stack, and change its control flow. Similarly, a program could mprotect its shadow stack, modify it, and mprotect it back. In some threat models, though could be seen as a WRSS bypass. (Although if an attacker can coerce a process to call mprotect(), the game is likely mostly over anyway.) But we could be more restrictive, or perhaps we could allow user code to opt into more restrictions. For example, we could have shadow stacks be special memory that cannot be written from usermode by any means other than ptrace() and friends, WRSS, and actual shadow stack usage. What is the goal? No matter what we do, the effects of calling vfork() are going to be a bit odd with SHSTK enabled. I suppose we could disallow this, but that seems likely to cause its own issues.