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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69B25C43217 for ; Tue, 8 Nov 2022 09:15:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233702AbiKHJPf (ORCPT ); Tue, 8 Nov 2022 04:15:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233726AbiKHJPa (ORCPT ); Tue, 8 Nov 2022 04:15:30 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D4252F009 for ; Tue, 8 Nov 2022 01:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667898867; 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=HvofJwMia+xRSBsOD4/cY+x14ahaw2Unb3Y1nWiIE/q6YbB6iRUTV+bpa0HpKqV43MsPeM V+5CCGEDt+m90xm2XUpeXJNmgouC3P8AGHMylLcUyzYKFTWL/kdzwzoI9kU76J6+DJh47f dbw3XfH7cWKJ18f+/kc8p4qYlXNYdv8= 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 Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org * 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