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 43D4AC4332F for ; Tue, 8 Nov 2022 09:14:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 851856B0073; Tue, 8 Nov 2022 04:14:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 828C76B0074; Tue, 8 Nov 2022 04:14:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F0B96B0075; Tue, 8 Nov 2022 04:14:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5F0396B0073 for ; Tue, 8 Nov 2022 04:14:32 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3C5D61A0474 for ; Tue, 8 Nov 2022 09:14:32 +0000 (UTC) X-FDA: 80109714384.16.5706D39 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 7493A1C0006 for ; Tue, 8 Nov 2022 09:14:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667898870; 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: in-reply-to:in-reply-to:references:references; bh=KP+tiCnk9vCKqrx4wl6vmjk9CSIgAcrzK2YQ6PLAxpU=; b=daO8bqcbbVjGEL1IKT2P6AM9fxKWRjP4Nw3CnIooR7TTPnBhV27r5j8WxTGf+lETNEhGeb 8fkYxyvFI6OGd+/vL7Nl+OhHN5JGlIrKZ9VYolUNCbp37QcetWobB4NAhYuY/wCQg9vMCb 4XmaeJcKX9ITePLPPHv7O+k5w9oedLU= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-178-Ut-AJcnsP0m_xLQD9tcXTQ-1; Tue, 08 Nov 2022 04:14:23 -0500 X-MC-Unique: Ut-AJcnsP0m_xLQD9tcXTQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1C9E41C06EE9; Tue, 8 Nov 2022 09:14:22 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.65]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B29FC4B3FC6; Tue, 8 Nov 2022 09:14:14 +0000 (UTC) From: Florian Weimer To: "Edgecombe, Rick P" Cc: "hjl.tools@gmail.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" , "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" Subject: Re: [RFC 37/37] fs/binfmt_elf: Block old shstk elf bit 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> Date: Tue, 08 Nov 2022 10:14:12 +0100 In-Reply-To: <73b8f726c424db1af1c10a48e101bf74703a186a.camel@intel.com> (Rick P. Edgecombe's message of "Mon, 7 Nov 2022 21:10:52 +0000") Message-ID: <87leolkduj.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=daO8bqcb; spf=pass (imf18.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667898871; a=rsa-sha256; cv=none; b=lTtogkvgz9D93TMVn2RYkArLT1OVocd5UvzweqGS1BA1D1tLOujBuAmsyUVsGnGFHt3Wiv sJtmajf/+AKHnpWXIZPvL+KvvRF04Mci/K6sCN4E6+OqNPLBdF5voN1MvjhrtL6meV2EVX UZrlWPb0NIswMII5vMapHEUAGm8I5Eg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667898871; 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=KP+tiCnk9vCKqrx4wl6vmjk9CSIgAcrzK2YQ6PLAxpU=; b=7wLZgOkNxnTK1IJLOFjwWIEX6SKECpSvGRktlwsJ38cdcguCTRn3plRsgt0BMY2wst7APj 1zs4owbB099IjbwkY1uiuzkNTudzWhRKUfZxSI7u1WZ1Gvo7DmLwuw0tmQTNA97R9+1nwe IqGLL8sQ5cmfNH2ezPlQAdJqX3vOHOE= X-Stat-Signature: i4yd6xh6jnujupmuhc64wo3crwqiu3fo X-Rspamd-Queue-Id: 7493A1C0006 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=daO8bqcb; spf=pass (imf18.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1667898871-181761 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: * Rick P. Edgecombe: > 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 > 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? This problem is fairly common nowadays for new system calls. Before glibc can use them internally, we need to port userspace first, otherwise key applications fail to work. Yet we do not require ELF markup to make the new system call available to glibc. The situation here seems similar: before deploying a new glibc, we need to upgrade parts of userspace. Thanks, Florian