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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 797C4C433F5 for ; Tue, 14 Sep 2021 09:53:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 12E836109E for ; Tue, 14 Sep 2021 09:53:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 12E836109E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8ACD46B006C; Tue, 14 Sep 2021 05:53:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 835F66B0071; Tue, 14 Sep 2021 05:53:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D760900002; Tue, 14 Sep 2021 05:53:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0115.hostedemail.com [216.40.44.115]) by kanga.kvack.org (Postfix) with ESMTP id 5A7F76B006C for ; Tue, 14 Sep 2021 05:53:24 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 23656180286FA for ; Tue, 14 Sep 2021 09:53:24 +0000 (UTC) X-FDA: 78585716328.36.4D127AC Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf28.hostedemail.com (Postfix) with ESMTP id AD3FF900009A for ; Tue, 14 Sep 2021 09:53:18 +0000 (UTC) Received: from zn.tnic (p200300ec2f1048004bf380b26d2cf776.dip0.t-ipconnect.de [IPv6:2003:ec:2f10:4800:4bf3:80b2:6d2c:f776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 07D1D1EC0453; Tue, 14 Sep 2021 11:53:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1631613192; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ViyruqyaOCoCW/0p2JZLgQLm3FfQGbXjvmpiABsrfCI=; b=RJB4znnZ3Vdx8xwIRKp/GquN5eUjvPjpfOZhxfz0G06K+1tAtY4CRKjGHkci8G6uqT909A hWeLlUA99oGVkIlEzNF1pgmmUafrY+0e3mG4RMHGGDr5b4CPS7Wv3qN3hMvbzoi15ZESpr gJLpU/Z822KRQonHTRZ/g1iP6GsO1d4= Date: Tue, 14 Sep 2021 11:53:06 +0200 From: Borislav Petkov To: "Edgecombe, Rick P" Cc: "Lutomirski, Andy" , "Hansen, Dave" , "bsingharora@gmail.com" , "hpa@zytor.com" , "esyr@redhat.com" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Yu, Yu-cheng" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "pavel@ucw.cz" , "linux-doc@vger.kernel.org" , "Yang, Weijiang" , "arnd@arndb.de" , "Moreira, Joao" , "tglx@linutronix.de" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "tarasmadan@google.com" , "Dave.Martin@arm.com" , "vedvyas.shanbhogue@intel.com" , "mingo@redhat.com" , "Shankar, Ravi V" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" Subject: Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack Message-ID: References: <5979c58d-a6e3-d14d-df92-72cdeb97298d@intel.com> <08c91835-8486-9da5-a7d1-75e716fc5d36@intel.com> <41aa5e8f-ad88-2934-6d10-6a78fcbe019b@intel.com> <45c62101c065ed7e728fadac7207866bf8c36ec4.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <45c62101c065ed7e728fadac7207866bf8c36ec4.camel@intel.com> X-Stat-Signature: jcsokpxnerjf6154untmstn5dh4wguux Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=RJB4znnZ; dmarc=pass (policy=none) header.from=alien8.de; spf=temperror (imf28.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: AD3FF900009A X-HE-Tag: 1631613198-324101 Content-Transfer-Encoding: quoted-printable 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 Tue, Sep 14, 2021 at 01:33:02AM +0000, Edgecombe, Rick P wrote: > The original prctl solution prevents this case since the kernel did the > allocation and restore token setup, but of course it had other issues. > The other ideas discussed previously were a new syscall, or some sort > of new madvise() operation that could be involved in setting up shadow > stack, such that it is never writable in userspace. If I had to choose - and this is only my 2=C2=A2 anyway - I'd opt for thi= s until there's a really good reason for allowing shstk programs to fiddle with their own shstk. Maybe there is but allowing them to do that sounds to me like: "ew, why do we go to all this trouble to have shadow stacks if programs would be allowed to fumble with it themselves? Might as well not do shadow stacks at all." And if/when there is a good reason, the API should be defined and discussed properly at first, before we expose it to luserspace, ofc. Thx. --=20 Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette