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 57EC8C6FD1F for ; Thu, 9 Mar 2023 23:52:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230044AbjCIXwB (ORCPT ); Thu, 9 Mar 2023 18:52:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229827AbjCIXwA (ORCPT ); Thu, 9 Mar 2023 18:52:00 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E22281102A5; Thu, 9 Mar 2023 15:51:58 -0800 (PST) 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 7096C1EC01CE; Fri, 10 Mar 2023 00:51:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1678405917; 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=2DAEMT8RlTvZl2+BqR845kghr2jrP8dvdCHxG77kors=; b=sNT2LjHr1xLCN8Hf+/O17MPOKXi8ykZLPI6+jeKeL8xBpnmXy8pmPgMKial0vCUmOIZ4Wn bykEQ5qA2QURxyKkcsl6dKoxr1bpvbycgolJ7SH8Jb81EfLPGAYWA9fSWN7qB6lmEiYVoi gUxgyBMJWKuf708XZCKlWUw/EPvJaAM= Date: Fri, 10 Mar 2023 00:51: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" , "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" , "Yang, Weijiang" , "Lutomirski, Andy" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "debug@rivosinc.com" , "linux-doc@vger.kernel.org" , "x86@kernel.org" , "andrew.cooper3@citrix.com" , "john.allen@amd.com" , "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: <20230309235152.GBZApxGNnXLvkGXCet@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org 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* > ... 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. 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? 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. 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. Also, it'll allow for faster fixing of all those shared objects to use shstk by way of political pressure. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette