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 C81C3C64EC4 for ; Thu, 9 Mar 2023 12:58:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F0E86B0075; Thu, 9 Mar 2023 07:58:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 37A26280002; Thu, 9 Mar 2023 07:58:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F399280001; Thu, 9 Mar 2023 07:58:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0CAB66B0075 for ; Thu, 9 Mar 2023 07:58:07 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C0D48C0F96 for ; Thu, 9 Mar 2023 12:58:06 +0000 (UTC) X-FDA: 80549362572.23.1C09499 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf11.hostedemail.com (Postfix) with ESMTP id CBBAA40004 for ; Thu, 9 Mar 2023 12:57:58 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=fDFEvQtH; spf=temperror (imf11.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="server fail" header.from=alien8.de (policy=temperror) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678366685; a=rsa-sha256; cv=none; b=pmqmPBVRQIyCJIBaV0lPew1YkQJcm71jZVSHJYmrD5x8O+y/LarPce4RayBofZkmHnM9+A qvg1UjwKukJSbLvn3DZr6YWdBXiRG82KsBJ4DTIX3hmZLutQPpskvyUwVAVrZ6jSAT29o7 LIIZDWgNO+KCd46NZrXXiwPhHUuHAbo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=fDFEvQtH; spf=temperror (imf11.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="server fail" header.from=alien8.de (policy=temperror) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678366685; 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=xQyqIfhwDtsH4v2hzkG71ZUDZ3mfvpSPc21bFOtyc8o=; b=YIgl1x+6c2hth3lhPjkUzogXYONRdDDRS2V+owlkziJPK9C9V7606rn/rHXDaswPbmfBrs 9LMr2KBmrhRYP3DH1K2EZmWnP3ZNOzzJW/nvmEGBXEMU5Mwa8CM2/STC+U1QzVfh9ScDsS HDQnl88T3x54cInDi6b2xbIwGnQYogs= 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 B3A8A1EC06C2; Thu, 9 Mar 2023 13:57:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1678366675; 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=xQyqIfhwDtsH4v2hzkG71ZUDZ3mfvpSPc21bFOtyc8o=; b=fDFEvQtHUkVd5hg2jwozRJNNeYEmJDaydIMnUV32Y1pbRgJfDXS1H4M5nX/CfYRKoCVihb 3ILX6KDKna6HwzKfng8Lw9jZ4oJyDn4iE9ih6v1/O7oCyW0hud4Jdm2vA1Y/q2Yt7FNSO6 8eSpKHVFnsUjVrFxdxE+EIORJXWBCZw= Date: Thu, 9 Mar 2023 13:57:52 +0100 From: Borislav Petkov To: "Edgecombe, Rick P" Cc: "david@redhat.com" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "dave.hansen@linux.intel.com" , "kirill.shutemov@linux.intel.com" , "Eranian, Stephane" , "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" , "Yang, Weijiang" , "Lutomirski, Andy" , "linux-doc@vger.kernel.org" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "akpm@linux-foundation.org" , "debug@rivosinc.com" , "jamorris@linux.microsoft.com" , "john.allen@amd.com" , "rppt@kernel.org" , "andrew.cooper3@citrix.com" , "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: <20230309125739.GCZAnXw5T1dfzwtqh8@fat_crate.local> References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> <20230227222957.24501-29-rick.p.edgecombe@intel.com> <9e00b2a3d988f7b24d274a108d31f5f0096eeaae.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9e00b2a3d988f7b24d274a108d31f5f0096eeaae.camel@intel.com> X-Rspam-User: X-Rspamd-Queue-Id: CBBAA40004 X-Rspamd-Server: rspam01 X-Stat-Signature: 94xyu3d9bbwbg379fq4eyw7wtqrc3ium X-HE-Tag: 1678366678-33883 X-HE-Meta: U2FsdGVkX19LSEZo3fE6F5qYjud0KfcPdXJhUkhBD4PgvTPO+GDPVqTwQRbU2lJzLY8aNFgWq513ZS9it9Z1FGbZM5qd7/TzoUQ9/GzIo0GBY6QbLMpGpTnOCfUH0z92ydZcJcfBS9LXOTaqZX3egUL4aRqDp+rRJIqtYND6JxHLEo8E4WMqP0JnvlNHXzvk5HaHGyxt4BZMBOqPv6nVgmkASRy9+xC6+EjlcXaDFDLXzgMpM/X0MzdMzOO4NTGbY9IhcmKOZ0fZH9DQyBnKfZ8nwSpFCVWV3KgNCtZuzIBmGlXHMqD2iaRuRUZPOZyAkOhb4t3+xQY/ftDo99lI/FDgWizuM331cL9u+55QZifvwQ1owvO2VZDYVwiYLKFHbUwRM0EECTSpE3t3/OWa/qZYDXWZAl50sqXg6drQ2McDgalaMhj6ZEeZkxovQsY/VBjxlKru4+AH89wKSVz11cpHINaEa2RoNacgYl/L4ZVlTR3E2yFbPXmZG6n/GbJb92HX3xuV77hRcyIcav+Us375hA/ABRX8aL/lhRosITMZ7SQTGId92BAnw6ZslJm+k2ogjowHkhp3kDk4VcIIiVagyT6495nPUwrv8sBwkabkcLcD3DH7v6DCHs/FD+TEHS8vn5IUdLFBEGE3P4/VdASptrv6ZzDHItYhQ2cuvVeaN/rkBqk+0bbp4VInr5QaRzJNNRBkkeogDLrNXd853ySYPuF+TUS1xFRu2Foa0Y5nDFbmkRX2DrZyQa8eY+gJfFDwAxUtoTo95/fdK+tOCqjttO7zCG3Q8OjvDMS/jO+K09Xj2YL6wYzvYPKKsK1QjMUkrT8AVx88C3aN6zEdfHnshdxxjzq29XflIcxAAashsSJb2GoLG+pCBwwN7riyc4QbgVrSnI5wQQ1ckWUMBHNlyM04RVhmM3VaeB+QSRlfJY4MY0vhi9+ZNn67Vj0JG2fG2mXFjGIS0Ac944E BoFHPuHc 2dsaNNBuIG5FmCQ5Kt1rkgiL7LICcWO6xCh++KWtLcEFwcKNTuom7LPSBHZVW9pStiym4ugDI1clCogoHT/AZb6fn8uC5wsr8Lic+Vkc2qiM+/OWaaEJk4+avaNHx/5tIai8llIeIgw9Iy6qdpHP8HUG2/0T9MrnXdqyvVGjee7smnz2bbR0i+pkQssi/pdEDacvJfNdaH0EkaZkt2xjVpfBCL3J7sJeK0/ZPZhPnjUoNsi5Nc7fqyaPRFd5SNUeaoCrzOLTNmRrKc3ocGc3ZYWmn+R2sFjq7YrrwVkvgq5OFvsPUTj/Z4AE1OqZvcvZFU+S50ABSIVzZ+ySchRTNXmchsOZs07fsoLD0pzJ798rKdWENi7lATdPSqPcEo9AGJpZju7TlUdQa3YY= 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 Wed, Mar 08, 2023 at 11:32:36PM +0000, Edgecombe, Rick P wrote: > This would be for things like the "permissive mode", where glibc > determines that it has to do something like dlopen() an unsupporting > DSO much later. > > But being able to late lock the features is required for the working > behavior of glibc as well. Glibc enables shadow stack very early, then > disables it later if it finds that any of the normal dynamic libraries > don't support it. It only locks shadow stack after this point even in > non-permissive mode. So this all sounds weird. Especially from a user point of view. Now let's imagine there's a Linux user called Boris and he goes and buys a CPU which supports shadow stack, gets a distro which has shadow stack enabled. All good. Now, at some point he loads a program which pulls in an old library which hasn't been enabled for shadow stack yet. In the name of not breaking stuff, his glibc is configured in permissive mode by default so that program loads and shadow stack for it is disabled. And Boris doesn't even know and continues on his merry way thinking that he has all that cool ROP protection. So where is the knob that says, "disable permissive mode"? Or at least where does the user get a warning saying, "hey, this app doesn't do shadow stack and we disabled it for ya so that it can still work"? Or am I way off? I hope you're catching my drift. Because if there's no enforcement of shstk and we do this permissive mode by default, this whole overhead is just a unnecessary nuisance... But maybe that'll come later and I should keep going through the set... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette