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 75A62C433FE for ; Mon, 7 Nov 2022 21:22:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B05508E0001; Mon, 7 Nov 2022 16:22:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A8E8A6B0073; Mon, 7 Nov 2022 16:22:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92F9F8E0001; Mon, 7 Nov 2022 16:22:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7FDCD6B0071 for ; Mon, 7 Nov 2022 16:22:27 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 44A39C069A for ; Mon, 7 Nov 2022 21:22:27 +0000 (UTC) X-FDA: 80107919934.15.95AF492 Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) by imf02.hostedemail.com (Postfix) with ESMTP id DD26D80009 for ; Mon, 7 Nov 2022 21:22:26 +0000 (UTC) Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-13b6c1c89bdso14137460fac.13 for ; Mon, 07 Nov 2022 13:22:26 -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=2p+o/wwFzaQT3YrtLLy11P/EQH0km3heDCq7YaIDuHE=; b=Kjm0WJEazxNniutHxpP/iWzp30/ucmFoXjNcrqKBpDby8wMAHcWjC5s4iDf2e1EXPU 9xz7D01nAcLCLqWCrR1zC2fFZzsjL+V0hbcDxyZ2MGgrOk0zHpKczXOloTnlEEv1deLg kB2xq9pVDzuFnsL69XzNC291l8iCoDoWbczQBS06d5MwKJP/7YjEoJEO/T4+gMdf6CU7 xOvRZApZvcxriK3UXAqxM81rho6C1vJkQy2v8jpIkMH8ly0JVq0kwdaaCwCucT9zVfEZ 2kDlegWL+kb1CarsoXje0G8gr736QSdt52a9sQSckDoMLfEAOO7/z3AB7Sc35g+EAExm Y6ig== 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=2p+o/wwFzaQT3YrtLLy11P/EQH0km3heDCq7YaIDuHE=; b=Okb89oVLxjSuRwFYhpn1JY60hHNUgkn3QHIOfyRnQEgosD1ZMHZYWbP8c3S9CiGFmO Eu3AOmQXk8bhGWbMzd+IGQzLqnEOkOgna1jFZ7xm6AkpnPmaCr+vCTJQSbmyiQIJa0q4 XWTMR+siZ0V/BwiPpEOPV5DWEMiIoXtviuzCVh6PmpDf832FsV5wi07iF8rQzPGgCKeW XZ+owKd15WXJKdXHLOr6QafWnkRpaet5QwH0DQ3jYSgRte1sfmNXCJdc0uvrMUFobLUH MV6MOoyVEVepke0K1pNQwPz9qCio8/gwP4GHvTAfz3wC2TfG/REreR10GoSHHI9OQ6BX xhhA== X-Gm-Message-State: ACrzQf1yweYO6QiTaJZkzPUiPQr83s5syFiGn/UxgVV4pYB5ELJspVxJ PgzviZm3RbqlDatyw4vM0juYbwNdFRuvWhxMgzk= X-Google-Smtp-Source: AMsMyM7zGoN0Xryx43RidskikH9G5CbyEmhHknjTpRv8ZR4Apq2ZIY5phqK71MLR9QxFCFZE96w1rWasCLWHB4wGK/8= X-Received: by 2002:a05:6870:f5a4:b0:136:3e0d:acdd with SMTP id eh36-20020a056870f5a400b001363e0dacddmr32962986oab.298.1667856145978; Mon, 07 Nov 2022 13:22:25 -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> <73b8f726c424db1af1c10a48e101bf74703a186a.camel@intel.com> In-Reply-To: <73b8f726c424db1af1c10a48e101bf74703a186a.camel@intel.com> From: "H.J. Lu" Date: Mon, 7 Nov 2022 13:21:49 -0800 Message-ID: Subject: Re: [RFC 37/37] fs/binfmt_elf: Block old shstk elf bit To: "Edgecombe, Rick P" Cc: "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" , "fweimer@redhat.com" , "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" , "akpm@linux-foundation.org" , "pavel@ucw.cz" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "linux-doc@vger.kernel.org" , "tglx@linutronix.de" , "john.allen@amd.com" , "rppt@kernel.org" , "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; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Kjm0WJEa; spf=pass (imf02.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.160.41 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=1667856146; a=rsa-sha256; cv=none; b=V/D3S224IhrRke/5bY2oNFhB3E/ClGsWvzhvDhXmt2nHzfmMbdD+sen5Y6wZpBGko01YHP NQhrtie7kpWX6SWqsksx/8IXI0qSYwZ2UhtKQ/umrgU+FIVUr5cEqVzb/cQH7CJC1278dD 2/i4/dUCGSHLGmkb56Y5+g5tfHQxjHE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667856146; 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=2p+o/wwFzaQT3YrtLLy11P/EQH0km3heDCq7YaIDuHE=; b=iPNnhqzS+PJNuKNLpvXqJtkCK9jp8HSPR9jxBj/Q5AWobwFhlnjXLOv6XthUgu7a/iO5aA LJhX9Z09BgAcnsSK1z9vJoI3D6Mcty7ZHWPsKeOHieA2MXFnu8zG0CF1edfhDICojHJj0x OY/vuEwEg/xjFbsUc91DnMKG2dU36Dk= X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Kjm0WJEa; spf=pass (imf02.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.160.41 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: DD26D80009 X-Stat-Signature: 8u4wnxq56bu4fuua37njxzd8knnq3epb X-HE-Tag: 1667856146-411236 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 1:11 PM Edgecombe, Rick P wrote: > > On Mon, 2022-11-07 at 11:10 -0800, H.J. Lu wrote: > > 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 d= isable > > > > 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. > > > > When we have everything in place, the problems would be much more > obvious when distros started turning it on. But we can't turn it on as Not necessarily. The problem will show up only in a CET enabled environment since build/test setup may not be on a CET capable hardware. > planned without breaking things for existing binaries. We can have both > by: > 1. Choosing a new bit, adding it to the tools, and never supporting the > old bit in glibc. > 2. Providing the option to have the kernel block the old bit, so > upgraded users can decide what experience they would like. Then distros > can find the problems and adjust their packages. I'm starting to think > a default off sysctl toggle might be better than a Kconfig. > 3. Any other ideas? Don't enable CET in glibc until we can validate CET functionality. --=20 H.J.