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 D553BC4332F for ; Mon, 7 Nov 2022 21:48:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B0066B0073; Mon, 7 Nov 2022 16:48:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 460668E0002; Mon, 7 Nov 2022 16:48:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 328246B0075; Mon, 7 Nov 2022 16:48:34 -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 1F0356B0073 for ; Mon, 7 Nov 2022 16:48:34 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C3D3A1209CF for ; Mon, 7 Nov 2022 21:48:33 +0000 (UTC) X-FDA: 80107985706.14.4BFC934 Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) by imf29.hostedemail.com (Postfix) with ESMTP id 6A189120007 for ; Mon, 7 Nov 2022 21:48:33 +0000 (UTC) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-13ae8117023so14225139fac.9 for ; Mon, 07 Nov 2022 13:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=I46IWU9HY2ruNBy3JjstNCm87DjtFShdlj2dycepamI=; b=nIrkWr7jjloh2uAuMz/dJfFAvESxMqswgPNAj0cN4PvnsyXfOEXPIdW/w5XRUtyZ66 GjRfZC3xVTE2hbJgF9HhnefWJEszLzFdHatbVc9B1lSPCARmDDtOOU9SHFA52ARys0N3 1iaF5k+52u242vUyC3Jn9HQOhamLi/eQefNj7WTUXetZ6Lve4u/fi1i0QDMFvXCy1/Ny B20x1p0+zxjxBZZekosoTISB/iiY+N1v/XXbZS62ZdQzrKkgvP/gz7wka6dhbuQhUJ4O 8ETkbJWYpk5hFp11MZOS2xG4Ste+XOc1YOCpZdB09ytSr37Nwd/NPlVdS3B3uELQN3eR UfJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=I46IWU9HY2ruNBy3JjstNCm87DjtFShdlj2dycepamI=; b=csygB6SYnhECM67uhIX3iOSqd2aamKDkfQb+ktOJ6ZajrffmmgZc7qdxABWUvpyy2W dSkjmiZcLPAvOEWuFsVo6wxtV9opebstOnK3SO7T5tofgLobMFB+7Tk5TYKfZNk4OeGv VLDnfSvf06NEbkPurlwpxLhmGyL2x3O4DCQirb1+WBKLaEqBcnF1QnHTmBq/Kc669JZB 9/1pyQiDKXYwIQtorISHHSmWXWJUzd1ROaEauyz2BG/KxL28ydSq43Bv5g/pKxxdndAR v1IcIQRWmV+htqtkriM+zHPGaWY6zO4HG1S6IOSTPIhQuyjc9FD+qSrvFO3Hfw3vbTBr HqUw== X-Gm-Message-State: ACrzQf1Yk5YmFuZXcAUQ2ggEUFt5l/yX6opbwT2t18Z8bM3j1H9d9Zug IjzP0yn8ovjVOFf1cO/h4Rb5+ws4r2M63mktf5o= X-Google-Smtp-Source: AMsMyM4gNGsRmPP0akudxVGkG68/crhXiv8O0loidyj+0lxizRpWSxU58sjRDG5uC8rpYM5nRMtUJ/WUywt+8i5cjHc= X-Received: by 2002:a05:6870:f5a4:b0:136:3e0d:acdd with SMTP id eh36-20020a056870f5a400b001363e0dacddmr33027556oab.298.1667857712559; Mon, 07 Nov 2022 13:48:32 -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> <31b5284ce7930835b055e4207059e4bea32367be.camel@intel.com> In-Reply-To: <31b5284ce7930835b055e4207059e4bea32367be.camel@intel.com> From: "H.J. Lu" Date: Mon, 7 Nov 2022 13:47:56 -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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667857713; a=rsa-sha256; cv=none; b=jVCnBAnsh0AHCGBfOsSx1hva3NZdwoDdNgZZDnLEs7hs3YH6tHglXv+quHfCK3THdjs70g WWStR7tvFcHso2aozquqI+zI9Tg/cqoD8IJfwqeNEYyjhQ2E5Jn5cdu6ZYTja6YERf+/Z5 2/xKLNdMW+c5ols2cBmbS1ZSZmbgkaI= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=nIrkWr7j; spf=pass (imf29.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.160.47 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667857713; 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=I46IWU9HY2ruNBy3JjstNCm87DjtFShdlj2dycepamI=; b=ijMBPDe/afZO6Uzja/BOe9vatvJf7e5Mkm9h5XTiQzj59unNB9/SVg3gAtSrU53HLSsNFR X1HiqCwmH4FAvb/1Xirkt8EQPx0ywH2NkqBPzsUYLMQFluaHlEphpuq7FzAtx6cjxVQL7P uLBDbSCBPxUaf9tDOXIu6OmgmWkd+FE= Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=nIrkWr7j; spf=pass (imf29.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.160.47 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6A189120007 X-Stat-Signature: a8ho8kt6ki1q9myy6qrbr7kt356waqgw X-HE-Tag: 1667857713-730697 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:34 PM Edgecombe, Rick P wrote: > > On Mon, 2022-11-07 at 13:21 -0800, H.J. Lu wrote: > > > > 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. > > Well, I'm not sure of the details of distro testing, but there are > plenty of TGL and later systems out there today. With kernel support, > I'm thinking these types of problems couldn't lurk for years like they > have. If this is the case, we would have nothing to worry about since the CET enabled applications won't pass validation if they aren't CET compatible. > > > > > 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. > > Can you elaborate on what you mean by this? Not upstream glibc CET > support? Or have users not enable it? If the latter, how would they > know about all these problems. The current glibc doesn't support CET. To enable CET in an application, one should validate it together with the CET enabled glibc under the CET enabled kernel on a CET capable machine. > > And what is wrong with the cleanest option, number 1? The ABI document > can be updated. It doesn't help resolve any issues. -- H.J.