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 19C4BC433FE for ; Thu, 13 Oct 2022 22:16:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 867B66B0071; Thu, 13 Oct 2022 18:16:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 818006B0073; Thu, 13 Oct 2022 18:16:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B8616B0074; Thu, 13 Oct 2022 18:16:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4EC306B0071 for ; Thu, 13 Oct 2022 18:16:23 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E7FE4AB9EE for ; Thu, 13 Oct 2022 22:16:22 +0000 (UTC) X-FDA: 80017335804.04.0D837EE Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 91E3F80024 for ; Thu, 13 Oct 2022 22:16:21 +0000 (UTC) Received: by mail-qt1-f172.google.com with SMTP id c23so2651149qtw.8 for ; Thu, 13 Oct 2022 15:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=B08O5vwoKAJbTDyb43gOoo2mIFVMU55F9hrLLIxw+10=; b=VLVRsF2N1UXUWLgAMwUAgkS9Mf7eQVzIjTfbntypnWe6qm9Z3KtDDy39b6vD8jkr5P IZE5itc/aOKHJ0oCcd98+bLOAh+Q8M30A1VZfAxrt7zUfyI/B2uj5aSDOWcDgD6us0y2 Bzv4L7bktYmJ/xs11x6JC1RkS1oxtPS7bOzixFr8Ok6/0+YpH2jYPC8QB4eDuCq63SAD L+j4sBpFxMSXyFtooXcBT4Y9FksrAkNo2LPcCvBtPY2qRfUf28ge4FWUH1Oz47nA/SoJ S+eDEBNFqEpJhHn0a0VO5j2D90rRMTtkQ+yS9EsDGlkLzYvBNbgfviHXqzbYWPGlzNlN npPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=B08O5vwoKAJbTDyb43gOoo2mIFVMU55F9hrLLIxw+10=; b=jfxj/Phd7U2DsWAnySNuqSjLKT1dNtYqLAXgJ2j0Pyp+apmU+I/ddeNxqGXwi80gO+ kLOqZRZSRyQDGHj07WDZslpvzN3TINzjvtQ4PgRjzACKuBma9TKU/D0zYKEwTc6HOJI7 A9QP2jXWI7dJ3w4YPlaHdszt+Q/voXsGyxqUkv1NOmO8doW9oF7PU3fJuHDCoZz5qPF4 60Ng9NVjUMO53CNHw3013LGsA06NrGHzPl5sBME0n3MpwPTJBGzw8Yrw3EYqUKabPMA7 p3511GI5kjLoKOTa/Rfwwq3bvQn2nNEKWKwBBN87658H8tq7Zja2fsFE93+SIt3ByyKr xV4A== X-Gm-Message-State: ACrzQf2NFz4dQ/YgfiX9IPo+uCxGnCcXJw7D8FdlwCy6Bo2Ie0IU+xVP Lp48LCjkQnGNaFa8RxQP9WUf8t1qTGGUaa/U+68= X-Google-Smtp-Source: AMsMyM769HQeJFCDkh2T1f1/le40tAoPrylONceFcsK+2+j6T/7xU/RnZ3TRzR+Xcg+PeuGRCvx3ugsugve0JzdB/Ks= X-Received: by 2002:ac8:6794:0:b0:39c:d44e:3682 with SMTP id b20-20020ac86794000000b0039cd44e3682mr1809700qtp.437.1665699380716; Thu, 13 Oct 2022 15:16:20 -0700 (PDT) MIME-Version: 1.0 References: <20220929222936.14584-1-rick.p.edgecombe@intel.com> <20220929222936.14584-2-rick.p.edgecombe@intel.com> <87ilkr27nv.fsf@oldenburg.str.redhat.com> <62481017bc02b35587dd520ed446a011641aa390.camel@intel.com> <87v8opz0me.fsf@oldenburg.str.redhat.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 13 Oct 2022 15:15:44 -0700 Message-ID: Subject: Re: [PATCH v2 01/39] Documentation/x86: Add CET description To: "Edgecombe, Rick P" Cc: "fweimer@redhat.com" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Yu, Yu-cheng" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "bp@alien8.de" , "oleg@redhat.com" , "Yang, Weijiang" , "Lutomirski, Andy" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "Moreira, Joao" , "tglx@linutronix.de" , "pavel@ucw.cz" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "linux-doc@vger.kernel.org" , "rppt@kernel.org" , "john.allen@amd.com" , "mingo@redhat.com" , "Shankar, Ravi V" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665699381; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=B08O5vwoKAJbTDyb43gOoo2mIFVMU55F9hrLLIxw+10=; b=dpuc0PMQU+je7MUZ4qAl4Z4N/7pfXXTCedN22fjOe/uYwhNK6pAMf30it5lMu/TajJsxs+ kmmD9VeFTGBDD0krj/I+JSrox/1IZBOER9GUbd8Knldazo2Xfs6g/bqphblTHzYcEzJgNi 5uNYleXcfOGm9r/TL4zCIsOPIxUsMHw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VLVRsF2N; spf=pass (imf30.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665699381; a=rsa-sha256; cv=none; b=5fa72Z+9RL4SyR83IiYNlPoYv8EmPu0YLqCrilWzmjZ2JLsHQJtIpHJuinE9MgrnkIQUwE u8kAS/KkxLgmK7MEGp51W66S/hMnqt+JG6oPhs0QZ2sNqkpD6Gc0X9hjwtkRos72j8XaWW 7RYvJT8qmFycBtuta0gkqTbUY8qbaEs= X-Rspam-User: X-Rspamd-Queue-Id: 91E3F80024 X-Stat-Signature: 6z5kx7911a6c8mysapzepbxpx5jftiro Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VLVRsF2N; spf=pass (imf30.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam10 X-HE-Tag: 1665699381-52443 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, Oct 13, 2022 at 2:28 PM Edgecombe, Rick P wrote: > > On Wed, 2022-10-12 at 14:29 +0200, Florian Weimer wrote: > > The ABI was finalized around four years ago, and we have shipped > > several > > Fedora and Red Hat Enterprise Linux versions with it. Other > > distributions did as well. It's a bit late to make changes now, and > > certainly not for such trivialities. In the case of the IBT ABI, it > > may > > be tempting to start over in a less trivial way, to radically reduce > > the > > amount of ENDBR instructions. But that doesn't concern SHSTK, and > > there's no actual implementation anyway. > > > > But as H.J. implied, you would have to do rather nasty things in the > > kernel to prevent us from achieving ABI compatibility in userspace, > > like > > parsing property notes on the main executable and disabling the new > > arch_prctl calls if you see something there that you don't like. 8-) > > Of course no one is going to implement that. > > > > (We are fine with swapping out glibc and its dynamic loader to enable > > CET with the appropriate kernel mechanism, but we wouldn't want to > > change the way all other binaries are marked up.) > > So we have these compatibility issues with existing binaries. We know > some apps are totally broken. It sounds like you are proposing to > ignore this and let people who hit the issues work through it > themselves. This was also proposed by other glibc developers as a > solution for past CET compatibility issues that broke boot on kernel > upgrade. I have to say, as the person pushing these patches, I=E2=80=99m > uncomfortable with this approach. I don=E2=80=99t think users will like t= he > results. Basically, do they want to upgrade and run a bunch of untested > integration with known failures? I also don=E2=80=99t want to get this fe= ature > reverted and I=E2=80=99m not exactly sure how this scenario would be take= n. > > But I hear the point about it not being ideal to abandon the existing > CET userspace. I think there is also a point about how userspace chose > to do this optimistic and early wide enabling, even if it was a bad > idea, and so how much should the kernel try to save userspace from > itself. So what do you think about this instead: > > The current psABI spec talks about the binary being compatible with > shadow stack. It doesn=E2=80=99t say much about what should happen after = the > loader. Since the greater ecosystem has used this bit with a more > cavalier attitude, glibc could treat it as a request for a warn and > continue mode. In the meantime we could have a new bit shstk_strict, > that requests behavior like these patches implement, and kills the > process on violation. Glibc/tools could add support for this strict bit > and anyone that wants to more carefully compile with it could finally > get shadow stack today. Then the implementation of the warn and > continue mode could follow that, and glibc could map the original shstk > bit to that kernel mode. So the old binaries would get there > eventually, which is better than the continuing nothing they have > today. > > And speaking of having nothing today, there are people that really want > to use shadow stack and do not care at all about having CET support for > existing binaries. Neither glibc or elf bits are required to use kernel > shadow stack support. So if it comes to it, I don=E2=80=99t want to hold > support back for other users because the elf note bit enabling path > grew some issues. > > Please let me know about what you think of that plan. The kernel CET description +The kernel does not process these applications directly. Applications must +enable them using the interface descriped in section 4. Typically this +would be done in dynamic loader or static runtime objects, as is the case +in glibc. may leave an impression that each application needs to use the kernel interface to enable CET itself. This is an option. But the updated glibc will enable CET automatically on behalf of the CET enabled application. If the glibc isn't updated to use the new CET kernel interface, the existin= g CET enabled binaries will run correctly under the new CET enabled kernel without CET enabled. --=20 H.J.