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 3C06CC64EC4 for ; Fri, 10 Mar 2023 11:41:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA0366B0072; Fri, 10 Mar 2023 06:41:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A50766B0074; Fri, 10 Mar 2023 06:41:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F1BF8E0001; Fri, 10 Mar 2023 06:41:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7CE1B6B0072 for ; Fri, 10 Mar 2023 06:41:12 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2D0F7140253 for ; Fri, 10 Mar 2023 11:41:12 +0000 (UTC) X-FDA: 80552797584.04.F16DBA7 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf11.hostedemail.com (Postfix) with ESMTP id 68CDB40009 for ; Fri, 10 Mar 2023 11:41:04 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=PkyOcRMZ; spf=temperror (imf11.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678448469; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aKpednaPACF1732v54TE1hryNVD7OhQPM/LLNaZm8es=; b=gWXHpINIEtxSya0EZVd8pfm9+H2MFqbUqo1naynxJDOctxVW8tuk3yJ3LxMsBRELm5Cda2 xX8O1iuUm1C9qABPjoVsUGMYd04FpFKtJ/zoknFZX1Omg5YwzOTLAIeh758grnmHpDwfcA lEhC6peSU95PeXnYjSlPKUp2QTqwQlU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=PkyOcRMZ; spf=temperror (imf11.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678448469; a=rsa-sha256; cv=none; b=h2dkc9+DgIDH/xtYBc8cAPLkwIJe+iEusclk7/M7Ygw6GzNc1Evv1z2x4C2pbSHXstKwOe oCrXJ8Oej1qEwBjN5DK+L5aQLPOfrQiVo0R5jM+Qn7Pg5WWrs3L1VrsWhLubo+NLIXXCUz d3Ho08T2zL0Qxw0MInAznB7adILaE1Y= Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (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 1E8241EC0505; Fri, 10 Mar 2023 12:41:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1678448461; 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:in-reply-to:in-reply-to: references:references; bh=aKpednaPACF1732v54TE1hryNVD7OhQPM/LLNaZm8es=; b=PkyOcRMZ+D8wX8CPrudIUxN7r3RAUM2G5EaHyz4Wkhd43r68Wqa8HFM4QXt1TMzCBdFu7n y++yFwAg6tFulnPDx5FJKV3NYcyRQINJpFEgTQpcCmPAiVIFg/71JqrhsNydRvTJKb26s8 vo0fFTAD6LwoT9NlYYQGVnvx7iTdbn8= Date: Fri, 10 Mar 2023 12:40:55 +0100 From: Borislav Petkov To: "Edgecombe, Rick P" Cc: "joao@overdrivepizza.com" , "david@redhat.com" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "pavel@ucw.cz" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "akpm@linux-foundation.org" , "Lutomirski, Andy" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "debug@rivosinc.com" , "Yang, Weijiang" , "x86@kernel.org" , "andrew.cooper3@citrix.com" , "john.allen@amd.com" , "linux-doc@vger.kernel.org" , "rppt@kernel.org" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" Subject: Re: [PATCH v7 28/41] x86: Introduce userspace API for shadow stack Message-ID: <20230310114055.GAZAsXR8cc3gLAZ8c0@fat_crate.local> References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> <20230227222957.24501-29-rick.p.edgecombe@intel.com> <9e00b2a3d988f7b24d274a108d31f5f0096eeaae.camel@intel.com> <20230309125739.GCZAnXw5T1dfzwtqh8@fat_crate.local> <20230309235152.GBZApxGNnXLvkGXCet@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 68CDB40009 X-Rspam-User: X-Stat-Signature: cxryexsixwbounqkg5uwx91tfkxqfp5t X-HE-Tag: 1678448464-89191 X-HE-Meta: U2FsdGVkX18NuhPFYkQ5VVoHw1GZMnpqzH3EcgykcLRB5NTikfJs//LzwzT/dTWG1gz+NeSUUpy8PMbgx8apaD76crvYi1CqzjNrWP3pRyheXYF0mNyB57vsvTkNV0ZOWGKYxK2DejOuyT6QKVDtUlhrYfSxsAXcNOLZAMHrud0MkgPLIOSP29nW7QbZVG/KbNtLr4KH8uushcmI4hOFgoCO75kqxPa5RZyugPY/qDlOg9bMAExUeq2hIpE0BroGK1WND5vJhxakq8ZB+f57pwzMHL7207g1PFvVDV3TSNC2ES70ifnzQv0IGDh9ZowxcLedtfeY/FG1Cx/8fIHAVyux9fH95P3b5D1cfBsEoMK3Um0+njevyhZiSiK+34dpljdxTsqCxcNYK7ww6jE6mrZwOe4wYZY53o4dBztT2JrCpbv8a3yiFfmGQwI1Q3QpU0JkTmg/XfsTAHXMZQmeQPmX43ER931ykx7voR1WI8ANQ1x+sW4XePs9LPNmCtQnu7fWYNu0DzDv8NUvyLZDLyFIBgHU7RnyTyN5KYp0E1viQd2mb6qdi2nRRDwoLlh12B+5rI0SHtAdsHB0rCJYVB7DuiOWfEVPxNTTZcBEr/8lgBaFmE4qd64HHIM/Zz68uYb2iLjOERXIT6cidiPccTgUFihsRU/yOyhXHJR5lLRgGjrtlEbJuW12aTH0N5RWvVq46qDiWDRk5R08/2q4ZrkROjgQmP6MU+Z3tFlUQRXRD311DDJU0TaklouOOfNYk+wOspyPpj4L/chCAZ2yCRqM9g97dAvGHzFoIJn2/uVYSgcI8O9cfzRUnGH6NNpCxOQaF7yHangEI5wcQzWqPx+N1oJB/INnA1tC2rMpgD7tN/XZ+E28daDDTvBTQQIs/1SaE+M1OSDDTynr9OD1qbbdvXboGZY6jwCxJLqC0t9tYeENwnVSRc99v2/FK8gf49xt61lYrmLaKDWDz9+ VyLCpD7+ a5V1ZWErLssIPGe9KB642wzHJcpa0esoqtq5vfR5zpS1khEVav8M8plrhpq1CXXnSDp4OuvS46+VVewIfL8x27H9EzY+jeBZLgGJSudEUNsMRIVgOW22ztc8P1k7UhKK0yTpSlJXU6uypAZWKMSKmQKUtLTgZKPYkswzXnVwfCjSZkTWCRbFUQIG5R5rWt91yVv1VuK0lQSbznbGF/0Lb0uFI1Y2ryOvOAJWyH7ssYRKroKgRtj7sR5etLEEaHEHPDHEeKoMq9NQ8emI277y7qlJpGwLaA5s8vd1ouVQJylPhi62AGuZwT+JCUEk7JVD2LTVjt8zp0shQ2Yh3hVLr9wu3nNE/gHsScZVz7zjEFfCgfD2AODMmem9uMIfCeHPlrgMqp/BrzrB5YV0uzk4Jt+WEg+t4yg8Kf4xiWT1A93ayEGiZmx0lz5dp8SxSVh2ObhHtsW3/R7Bpxro= 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 Fri, Mar 10, 2023 at 01:13:42AM +0000, Edgecombe, Rick P wrote: > See "x86: Expose thread features in /proc/$PID/status" for the patch. > We could emit something in dmesg I guess? The logic would be: dmesg is just flaky: ring buffer can get overwritten, users don't see it, ... > The compatibility problems are totally the mess in this whole thing. > When you try to look at a "permissive" mode that actually works it gets > even more complex. Joao and I have been banging our heads on that > problem for months. Oh yeah, I'm soo NOT jealous. :-\ > But there are some expected users of this that say: we compile and > check our known set of binaries, we won't get any surprises. So it's > more of a distro problem. I'm guessing what will happen here is that distros will gradually enable shstk and once it is ubiquitous, there will be no reason to disable it at all. > You mean a late loaded dlopen()ed DSO? The enabling logic can't know > this will happen ahead of time. No, I meant the case where you start with shstk enabled and later disable it when some lib does not support it. >From now on that whole process is marked as "cannot use shstk anymore" and any other shared object that tries to use shstk simply doesn't get it. But meh, this makes the situation even more convoluted as the stuff that has loaded before the first shstk-not-supporting lib, already uses shstk. So you have half and half. What a mess. > I hope non-permissive mode is the standard usage eventually. Yah. > I think if you trust your libc, glibc could implement this in userspace > too. It would be useful even as as testing override. No, you cannot trust any userspace. And there are other libc's beside glibc. This should be a kernel parameter. I'm not saying we should do it now but we should do it at some point. So that user Boris again, he installs his new shiny distro, he checks that all the use cases and software he uses there is already shstk-enabled and then he goes and builds the kernel with CONFIG_X86_USER_SHADOW_STACK_STRICT=y or supplies a cmdline param and from now on, nothing can run without shstk. No checking, no trusting, no nothing. We fail any thread creation which doesn't init shstk. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette