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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A30D8C433FE for ; Mon, 31 Jan 2022 18:27:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D09B26B00E0; Mon, 31 Jan 2022 13:27:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CB8976B00E2; Mon, 31 Jan 2022 13:27:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B80246B00E3; Mon, 31 Jan 2022 13:27:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id A83A86B00E0 for ; Mon, 31 Jan 2022 13:27:26 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5D4F71822D2A2 for ; Mon, 31 Jan 2022 18:27:26 +0000 (UTC) X-FDA: 79091414892.12.8F3203A Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf26.hostedemail.com (Postfix) with ESMTP id C5D21140004 for ; Mon, 31 Jan 2022 18:27:25 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id s6so7649996plg.12 for ; Mon, 31 Jan 2022 10:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r4xwJBi8q1FRa6SCCAyqdRaLBggch8TnlaM4QVC5L6s=; b=qE9n/zRiSBommfNv+Ylzgyl4CHXyFBAjKvVHTQ792Gi4mzAtyJFsUes4Iz130ZUigW mhlzucT9wN07qCC60leuIX7WsKtl2ubbqHHcgny8hGXpPYTjk/UzuNfmdMPnUpyDCPzl +NmEdOUvimEtOUQ0qV++b0NEQdzPFbUZXbg2YaS5u2u/Tn29oOLv0c21gGugpgGWqvb5 SEyXRORSWstaGohz48PdB2o5gcCNbO9CTp9lkJEoFm3cGM0UbLfUjK92tESxnI/YAdRN w8dU0sI6ubF5nsNTQjI5D91UmNRmYGPjo0K/gU3LI8oQ+k76wgyWRknu/MCR1dRtES7F gk1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r4xwJBi8q1FRa6SCCAyqdRaLBggch8TnlaM4QVC5L6s=; b=ThbBgKu2DuMnKJr6JcH+N5oN7MfWq8Oehjf141piY4cKU0dWf1smkHxs5ccPFhWDAw Kx8vkteBRY/KsFIcVUvH6uwbwRzBx2JlIW8fJllxBOekaq264Xhsp0fEL/QkMwlODNp7 8XNM6VTtn6sRDYGmBz7R8scJBwzCPSMve3gw7f1nC5gtCbt9lrfJViYLOISWAyeDRdSi jeQUiPkaumYvLTG1L60rRo3zdWMlCqDCRfVbuvD8rUwpKl7rpYuBacXQiaFKwMs/omZU 4emfbMDf6ogpK4u3D4tPDQRVGk++BySdisLh2SHHjQWYavInGOnaxbEMQe4sieiq3QdN 5Ppw== X-Gm-Message-State: AOAM533Q0rMcTqDkkpeTfgr6LpUUiL3x28IMAq9qzb9d9ZAxhhDSGarG pp6dr5JIo60TX2e8nphBiI/HVou6ZR5kxhlaiqw= X-Google-Smtp-Source: ABdhPJw+fHsfw5UduK45wmBxPkeMk2UrZFl5cMQOPBj0yL+xKr7ja/LjgHWM13r4g3FwaPfZ+egF5l23vsHygbdb++o= X-Received: by 2002:a17:90b:4f83:: with SMTP id qe3mr35727324pjb.120.1643653644745; Mon, 31 Jan 2022 10:27:24 -0800 (PST) MIME-Version: 1.0 References: <20220130211838.8382-1-rick.p.edgecombe@intel.com> <20220130211838.8382-35-rick.p.edgecombe@intel.com> <87wnig8hj6.fsf@oldenburg.str.redhat.com> In-Reply-To: <87wnig8hj6.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Mon, 31 Jan 2022 10:26:49 -0800 Message-ID: Subject: Re: [PATCH 34/35] x86/cet/shstk: Support wrss for userspace To: Florian Weimer Cc: Rick Edgecombe , "the arch/x86 maintainers" , "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Andy Lutomirski , 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" , Dave Martin , Weijiang Yang , "Kirill A . Shutemov" , joao.moreira@intel.com, John Allen , Kostya Serebryany , Stephane Eranian Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: C5D21140004 X-Stat-Signature: nqizifpkz594477rkuh5dtdo4u7wqrdh Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="qE9n/zRi"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com X-Rspam-User: nil X-HE-Tag: 1643653645-624098 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 Sun, Jan 30, 2022 at 11:57 PM Florian Weimer wrote: > > * Rick Edgecombe: > > > For the current shadow stack implementation, shadow stacks contents cannot > > be arbitrarily provisioned with data. This property helps apps protect > > themselves better, but also restricts any potential apps that may want to > > do exotic things at the expense of a little security. > > > > The x86 shadow stack feature introduces a new instruction, wrss, which > > can be enabled to write directly to shadow stack permissioned memory from > > userspace. Allow it to get enabled via the prctl interface. > > Why can't this be turned on unconditionally? WRSS can be a security risk since it defeats the whole purpose of Shadow Stack. If an application needs to write to shadow stack, it can make a syscall to enable it. After the CET patches are checked in Linux kernel, I will make a proposal to allow applications or shared libraries to opt-in WRSS through a linker option, a compiler option or a function attribute. -- H.J.