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 22222C64EC4 for ; Fri, 10 Mar 2023 02:04:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80F446B0072; Thu, 9 Mar 2023 21:04:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BF4F6B0074; Thu, 9 Mar 2023 21:04:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63A9E6B0075; Thu, 9 Mar 2023 21:04:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5469A6B0072 for ; Thu, 9 Mar 2023 21:04:29 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2F83C1A076C for ; Fri, 10 Mar 2023 02:04:29 +0000 (UTC) X-FDA: 80551344258.25.6AADB31 Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf09.hostedemail.com (Postfix) with ESMTP id 791A9140007 for ; Fri, 10 Mar 2023 02:04:26 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FreEnRmt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678413866; 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=ZpXYGsa+/tLjP2Tn48cDkgbawf4lLCTFCHOzj/xyJow=; b=yqzCD2xS0EBFzAh0MQB2o6K4p1crf3tkwWoO48eqkhaYaennyxryJJWDeLgDdQBOh8bUBT SXu1mZzcW8yimKz4OyyAqyEIlQ1EgVaXGyH0SKaTvIPyeGt87V5r9nMQ1RA6QbWU5n6Gzn C+JfviMrTaRH+KYRW+nuD4V4QFxhsE4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FreEnRmt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678413866; a=rsa-sha256; cv=none; b=sttGe/hr+AHCrdi/OI/NLv/Z5OvxVdOfFlwO6rA1xLGzlcJ7JYdXe4F4HI9j5lz998n2UX 7jBxs3AW/MJLhTwYZGS6uBIyJHHIsXz+vCNj5cYy0DNbC3N6L8UwV7IiP9ejw4DjyJDI8L DMMicTMbgJ2YIrcNmD5YFOGC6epTz1U= Received: by mail-yb1-f171.google.com with SMTP id q8so3950974ybu.5 for ; Thu, 09 Mar 2023 18:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678413865; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZpXYGsa+/tLjP2Tn48cDkgbawf4lLCTFCHOzj/xyJow=; b=FreEnRmtxv7vK9X3Rz/OCq/dHqlNMrviZmmMz1IGFTWD6t8sMLyD74Pbo98t47bXJs rUGmdXXtxCX/eMlIQzuuaz2loEi/Kezj/jl5qo3Lcv1wag3bJuoTXHVviKnqHG9Sa2KO jedNffaFMguCPPyO7TV4kui3NNLz9arc1RCSiE0aEgfEoXNjiHG1PSt0ST2mf6pXzKNQ 8Qn063W5CnNMyPeu6PqNMTOucwKveWLeW7euOt+JFc8LTLyBVa2GBss9F0mv/1yigN80 dWwlHvx5z+cRpRGErVKu4atXdyQv5H7KeVdtcQ7jRoctW7BX73smfk7SqKTUK3dLeyVN W6LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678413865; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZpXYGsa+/tLjP2Tn48cDkgbawf4lLCTFCHOzj/xyJow=; b=XKdliFlFsT6VqFcnqQzcZQcHvDdZ5PZKQaYg6ztH/aSh4V0Y1jBYy7Qr+pCoYSHmmt U+TlBX3QY3VctcPHqzDkJMjg6p4n/VCiJaP3DyuoXl2YgUZed5lkahqiSNC+zmedtUF6 ZWilfwi2HQBAjE/tczZ0CzuCrMpPsFIB4FA5V73IlxrV7PacsEzdDawcakmZEFIrPtUk Ye2nAqVr8UHiZjJZhEZ1280PkpSiUr8zb58RmFseSGRGOmGe8O4z/ArBcrcu+FPW3SKe AW+Dxs1r/GRpvTCV4TGHSqVxLrjp8scWFCARAe54mXaq+mIAmzzIXj8Vin4xGk3yHCIX aECw== X-Gm-Message-State: AO0yUKUR3MAzB+j/egaz8xK0vb3sZDk1vj9jbsrccIwa0lPIlGY89aGd RbK2Us/JVxNh0djHV+Xv42xekI4kipxRULSrZoM= X-Google-Smtp-Source: AK7set+BzG4Y5/Y1p12HS5COJNsg/gn4zCEjqL4Y9+Nj5gQFEqZabeD0GfIzWLBeO2AJRdvi92kIprvewGSCAgfoB0s= X-Received: by 2002:a5b:38a:0:b0:ac9:cb97:bd0e with SMTP id k10-20020a5b038a000000b00ac9cb97bd0emr11690269ybp.5.1678413865512; Thu, 09 Mar 2023 18:04:25 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: "H.J. Lu" Date: Thu, 9 Mar 2023 18:03:49 -0800 Message-ID: Subject: Re: [PATCH v7 28/41] x86: Introduce userspace API for shadow stack To: "Edgecombe, Rick P" Cc: "bp@alien8.de" , "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" , "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" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 791A9140007 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: oxcrs1gi3b4o6rbeacbhfs1bfcgsmgfm X-HE-Tag: 1678413866-765981 X-HE-Meta: U2FsdGVkX19B79qNRFlsETtMihW0JOik/UvVcmBm9T6Di1j6HtDfRj7Jr4G4EWkO2AoyR1d1dEImIySOjbPNDc0Pklk2Zyy5XzKvg/lzb1GEdDD5cjvcvBd2H1K5Asir82O+Vv1YMVU1ralWAU3dP6gk8rr8lwwUjk0/77csWl57H6Rls5Yo7tKRHSWTzJIQzWyiEO/5woVJU+/CKeZiaexeg8MY/29WdYf+RelSqK6UnES7P84AJ5gFqlCJLX5i46dZ3IzZ2zwJ5z1Zal29dzZXLAHs0LrWBRiCO3sMSTB9/zY1pRECq62QjwqTtLGV7g5KsO/Ijf5+1KWDw3Y2NHuUsnlb8vuyke7uCXuUQoV+haRHZOpXBRBymvwGe5cfIGm7tGfD5qX3SYBAX3xsfLhbn1C0NEEJceriZbMS0QzDzPlGl3jCvHsuLlB3k/kJWFmT3Pil/lqjru3i09i7ZyZXgbAg38UI3CzU5LzNK9bQf3CfDnF2rRO6QCxcemsNH2dJtDM7dkLFK3VXVXN0osm3b+QBsdxDSgGRyW1gxC2gymasPO9U0Uue0CL2bDhj9rFHIUtV7Q7fAd+0CIWWwurvEfS5wqQMNoRU5BMjWZBGmn8oOgI9scxpNvpHN59E/Dwex4tdRKohU8qDlDw0IY+iyuLJBFBi1LrQ/9YV7Twc4/swhLR45rGbQZL65GWAM4eCwquqXQKxGEctz6LhswkKjJmUxMW5aY9TjcNnMv6ipjRDfw4Q551ERyc/MWPRs4Uh9ZyKmocVKuprRJm/exXJk/N2nBbdCmb3/f4Yr2UGZVZG8547mRMdI31WM2whzSyc7vkDqerEIRjhXW1tB3mnTRAP3kNoBUGAo2GM23GM+tXPWmOKIZ7RUDvGfbDY1nOhyJ21ZL2/9Rpv5Ym58zp3YRTJrtk3xdtC87ztTOt+dry5hPTppcEehKTzFVD9TxxbsTw0N46FhIC4wXi LXZShew2 ECFooTh4BjfJkLh2gOp+aGLkuwmaGyRAnw2g0v+UpLqgGmKAWeHBjxuY36mfSMqwVJcZu/ePCFaIB3sa14XFnPkki+gxttYfJRiOmlescYJ41LjE5cwUtWoY/8bfJ4+kUE6JoDO5g73YCWlqRbgyO0aHO3lXnRAYd77cj3C/SPqt8Jn+Jfur6ivIMSHrkKefmwdu2qH+kXmgP0n6gX+FeXY3hoQ2FnWX98LzPtnmlFu6LMjfVMbiFu7sDFmf4oXKcyt+16mgUj9QMOk752i13vI5BCnaZ60VyUNG2XZrntzfxBbSgG/JWZho7WqbBRsbQEMGaU/anuTkdJ9fD1Z0CnPzzyoaDa7Chg3oAhGQpLsTvykVw8SbbGYdM5mNiZBLxwv2P5kwVVTpdkODETFrudc8zjZeVt+ivb0XotpMuqdcK5Cq3yv2A/+VsACnXB39mLNtn2RCzOrEJqZpaYShUUUd2X5wGukNWfXNT73E/nixjUDEDMugIe0JEOZd2dUasNAGNxTK4TTrLjsyBOIRFCcATVXvvrj+b6a1c 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 Thu, Mar 9, 2023 at 5:13 PM Edgecombe, Rick P wrote: > > +Joao regarding mixed mode designs > > On Fri, 2023-03-10 at 00:51 +0100, Borislav Petkov wrote: > > On Thu, Mar 09, 2023 at 04:56:37PM +0000, Edgecombe, Rick P wrote: > > > There is a proc that shows if shadow stack is enabled in a thread. > > > It > > > does indeed come later in the series. > > > > Not good enough: > > > > 1. buried somewhere in proc where no one knows about it > > > > 2. it is per thread so user needs to grep *all* > > See "x86: Expose thread features in /proc/$PID/status" for the patch. > We could emit something in dmesg I guess? The logic would be: > - Record the presence of elf SHSTK bit on exec > - On shadow stack disable, if it had the elf bit, pr_info("bad!") > > > > > > ... We previously tried to add some batch operations to improve > > > the > > > performance, but tglx had suggested to start with something > > > simple. > > > So we end up with this simple composable API. > > > > I agree with starting simple and thanks for explaining this in > > detail. > > > > TBH, though, it already sounds like a mess to me. I guess a mess > > we'll > > have to deal with because there will always be this case of some > > shared object/lib not being enabled for shstk because of raisins. > > 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. > > 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. > > > > > And TBH #2, I would've done it even simpler: if some shared object > > can't > > do shadow stack, we disable it for the whole process. I mean, what's > > the > > point? > > You mean a late loaded dlopen()ed DSO? The enabling logic can't know > this will happen ahead of time. > > If you mean if the shared objects in the elf all support shadow stack, > then this is what happens. The complication is that the loader wants to > enable shadow stack before it has checked the elf libs so it doesn't > underflow the shadow stack when it returns from the function that does > this checking. > > So it does: > 1. Enable shadow stack > 2. Call elf libs checking functions > 3. If all good, lock shadow stack. Else, disable shadow stack. > 4. Return from elf checking functions and if shstk is enabled, don't > underflow because it was enabled in step 1 and we have return addresses > from 2 on the shadow stack > > I'm wondering if this can't be improved in glibc to look like: > 1. Check elf libs, and record it somewhere > 2. Wait until just the right spot > 3. If all good, enable and lock shadow stack. I will try it out. > But it depends on the loader code design which I don't know well > enough. > > > Only some of the stack is shadowed so an attacker could find > > a way to keep the process perhaps run this shstk-unsupporting shared > > object more/longer and ROP its way around the system. > > I hope non-permissive mode is the standard usage eventually. > > > > > But I tend to oversimplify things sometimes so... > > > > What I'd like to have, though, is a kernel cmdline param which > > disables > > permissive mode and userspace can't do anything about it. So that > > once > > you boot your kernel, you can know that everything that runs on the > > machine has shstk and is properly protected. > > Szabolcs Nagy was commenting something similar in another thread, for > supporting kernel enforced security policies. I think the way to do it > would have the kernel detect the the elf bit itself (like it used to) > and enable shadow stack on exec. If you can't rely on userspace to call > in to enable it, it's not clear at what point the kernel should check > that it did. > > But then if you trigger off of the elf bit in the kernel, you get all > the regression issues of the old glibcs at that point. But it is > already an "I don't care if I crash" mode, so... > > I think if you trust your libc, glibc could implement this in userspace > too. It would be useful even as as testing override. > > > > > Also, it'll allow for faster fixing of all those shared objects to > > use > > shstk by way of political pressure. -- H.J.