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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7F43C4332F for ; Mon, 31 Jan 2022 18:27:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350718AbiAaS10 (ORCPT ); Mon, 31 Jan 2022 13:27:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350686AbiAaS1Z (ORCPT ); Mon, 31 Jan 2022 13:27:25 -0500 Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 403B2C06173B; Mon, 31 Jan 2022 10:27:25 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id d18so13219575plg.2; 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=43grz6Mm9pGfYfgJsRzvXFMowyh8JwyvJ/C0dtJt5SYxVAMRuEISjwc1Lxbc+iB4dI 09Z0ghzfzCqJ8tZtqb07EAJ5U4HHCgKDiiOFV4fetIBcrtrIwAseCwiUUjGrQsdA2uyX r+UUTVCGZzeJduE3uCY3f+R5iVBaI0GbRBLc3ll/WPJ8UmEtziOhZrYv2Yi0r36rVAK3 zzVUDpqgbOCwGjuP8yES9p7bXFZO/b2DscEZAreso5y6ywUt+aHB8dFfdngJZP/aZftx uvnkdJqSAPeB4Yj7HKiNkNea76kwH4RqcIVAaOOsBtmyRS9xe6dCndBPvOjG8kuR+fE3 leKw== X-Gm-Message-State: AOAM5308wAyQCOFC/ffH+JhdpfieNwiocd1jozAXxvayW4PrF9waZEhi 86OlOOWl5BAIjUo9Sx8MR9sx1asagYkMD6qYK7E= 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" Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org 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.