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 C0FB7C433FE for ; Mon, 7 Nov 2022 19:10:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C2C36B0078; Mon, 7 Nov 2022 14:10:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 54BC08E0002; Mon, 7 Nov 2022 14:10:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C5238E0001; Mon, 7 Nov 2022 14:10:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 288766B0078 for ; Mon, 7 Nov 2022 14:10:54 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DB5801A1015 for ; Mon, 7 Nov 2022 19:10:53 +0000 (UTC) X-FDA: 80107588386.09.C5850E2 Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) by imf08.hostedemail.com (Postfix) with ESMTP id 76C32160005 for ; Mon, 7 Nov 2022 19:10:53 +0000 (UTC) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-13bef14ea06so13792597fac.3 for ; Mon, 07 Nov 2022 11:10:53 -0800 (PST) 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=CnSdXKK8m/TJrSRjpKbt+NCWqdZs41kIo7jBijs/TeU=; b=dFI57mVeLdLCTF/+XJv4MLgt8AJf00hHj1SZ1TvShHINC1AeiIpsTbJYQD0PpD8f2P qyPIVPZbddFysDwm2/vv5n2pw/HvJ/hzgwF/9jBnbTb33IjvkaisUl4ESgfaaVhM2h32 Xc4sfsZB/Gnhnv2c+FbMk09/2hIVbVRtc357MkZuqAXJ8pPaN5GUAtBSZZe73KZHZ7l0 k3S9AYKJCFC2jrHqhX1BosNVb2BaF3M89cW7lxDFkyLs9vwkfhKruqHcqNPN9bqteOPQ P1IjYbSEGQSwSCkxZD0LwMdigGUJLKm4pSk6NTb/hGht89+/Dv7sBZmtG+w3oN18FErQ EoiA== 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=CnSdXKK8m/TJrSRjpKbt+NCWqdZs41kIo7jBijs/TeU=; b=Kep7fuxbVe+/vxdA91GEPK16hfIoKolS0ED9rhcQ6rmdgMetVY23T8P6Vwn2MKkgMX QTNodlvfgdGWyXb9qvHCsVh4gGO/GL9JBmf5axaihbtC3q8n9m0C7NH4DDJnJlwA4sKP Ly6X59H0TGL0dzf2yh+8qqE2gdtjsIErtaVYSw+JCU+nCrX/c4QmvISfN1hiWMQ2zD/s GIZt+JvV8vbi2eKYlHbKEhR0TAk32oSN8TktHaf74mcJLWqlQUaHHepM6ZCDsY1N3DNp +Est9UgvN3wo8IMhMRTSzJ1RC6Qjo3GNwaPGskgnfWRgeHVHq9u0UGYRnH5nNR4tiB6p +zcA== X-Gm-Message-State: ACrzQf1tRNrEsPWl4JBJTksaYxRBra3o+bLJlcnfdgBYG+UoGD+lxrvo A4qCzb/2pTe6RTrjOEyoGdpbx6oM9Tqo87wjdpM= X-Google-Smtp-Source: AMsMyM6GiJyh9IyvmqNZZBHIGsfQJ6ZN9HLdU10rJi8jcabtIPMfsFwGxHxzce8ZZIo8zTZtoeKLCPwKDzdaxWY8cIQ= X-Received: by 2002:a05:6870:f5a4:b0:136:3e0d:acdd with SMTP id eh36-20020a056870f5a400b001363e0dacddmr32579634oab.298.1667848251194; Mon, 07 Nov 2022 11:10:51 -0800 (PST) MIME-Version: 1.0 References: <20221104223604.29615-1-rick.p.edgecombe@intel.com> <20221104223604.29615-38-rick.p.edgecombe@intel.com> <87iljs4ecp.fsf@oldenburg.str.redhat.com> <87h6zaiu05.fsf@oldenburg.str.redhat.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 7 Nov 2022 11:10:14 -0800 Message-ID: Subject: Re: [RFC 37/37] fs/binfmt_elf: Block old shstk elf bit 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" , "linux-doc@vger.kernel.org" , "pavel@ucw.cz" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "akpm@linux-foundation.org" , "tglx@linutronix.de" , "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-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dFI57mVe; spf=pass (imf08.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.160.42 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=1667848253; a=rsa-sha256; cv=none; b=f9J1cHDXNVcv9Aloz/DGeulXwH1Hir3AhWP4ECfb4w31Adr9o2xx3+HzaDNr8GPQBSXYem alvXqIX5jI6LqO+Yicpx/POwjxbELdlg00ynXsRi/VnwdttwUaWa+oMQpFpEbhUExJ5OGp bwqosvSGpeYgLwUdMYqThpSWUUnnO7g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667848253; 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=CnSdXKK8m/TJrSRjpKbt+NCWqdZs41kIo7jBijs/TeU=; b=mKtPExjCUs2n4Ulb1eMpeVP2xPaBcoiL8eIWq6O5c1B+NhcyrBjDatBexAmCsmHZ3MoeCJ 34AaeCl9/MhEQ5sXbYrCA1pJER2cQGJq3qZp+jJyA+dIzSjd3pDPxIHm0LDKm1PGuimhL4 aVBDSQ6fljF6lJI/9gLgAa8FFRroy5I= X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dFI57mVe; spf=pass (imf08.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.160.42 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 76C32160005 X-Stat-Signature: 31o5k83e3imn19uz6updgkzsg9szikd3 X-HE-Tag: 1667848253-883298 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 Mon, Nov 7, 2022 at 9:47 AM Edgecombe, Rick P wrote: > > On Mon, 2022-11-07 at 17:55 +0100, Florian Weimer wrote: > > * Rick P. Edgecombe: > > > > > On Sun, 2022-11-06 at 10:33 +0100, Florian Weimer wrote: > > > > * H. J. Lu: > > > > > > > > > This change doesn't make a binary CET compatible. It just > > > > > requires > > > > > that the toolchain must be updated and all binaries have to be > > > > > recompiled with the new toolchain to enable CET. It doesn't > > > > > solve > > > > > any > > > > > issue which can't be solved by not updating glibc. > > > > > > > > Right, and it doesn't even address the library case (the kernel > > > > would > > > > have to hook into mmap for that). The kernel shouldn't do this. > > > > > > Shadow stack shouldn't enable as a result of loading a library, if > > > that's what you mean. > > > > It's the opposite=E2=80=94loading incompatible libraries needs to disab= le > > shadow > > stack (or ideally, not enable it in the first place). > > The glibc changes I have been using would not have enabled shadow stack > in the first place unless the execing binary has the elf bit. So the > binary would run as if shadow stack was not enabled in the kernel and > there should be nothing to disable when an incompatible binary is > loaded. Glibc will have to detect this and act accordingly because not > all kernels will have shadow stack configured. > > > Technically, I > > think most incompatible code resides in libraries, so this kernel > > change > > achieves nothing besides punishing early implementations of the > > published-as-finalized x86-64 ABI. > > It's under the assumption that not breaking things is more important > than having shadow stack enabled. So it is not intended as a punishment > for users at all, rather the opposite. > > I'm not sure how much the spec mandates things by the letter of it, but > in any case things have gone wrong in the real world. I am very open to > discussion here. I only went this way as a last resort because I didn't > hear back on the last thread. Some applications and libraries are compiled with -fcf-protection, but they manipulate the stack in such a way that they aren't compatible with the shadow stack. However, if the build/test setup doesn't support shadow stack, it is impossible to validate. --=20 H.J.