Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Florian Weimer <fweimer@redhat.com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc:     "hjl.tools@gmail.com" <hjl.tools@gmail.com>,
        "bsingharora@gmail.com" <bsingharora@gmail.com>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "Syromiatnikov, Eugene" <esyr@redhat.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "rdunlap@infradead.org" <rdunlap@infradead.org>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "Yu, Yu-cheng" <yu-cheng.yu@intel.com>,
        "Eranian, Stephane" <eranian@google.com>,
        "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "nadav.amit@gmail.com" <nadav.amit@gmail.com>,
        "jannh@google.com" <jannh@google.com>,
        "dethoma@microsoft.com" <dethoma@microsoft.com>,
        "kcc@google.com" <kcc@google.com>,
        "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
        "bp@alien8.de" <bp@alien8.de>, "oleg@redhat.com" <oleg@redhat.com>,
        "Yang, Weijiang" <weijiang.yang@intel.com>,
        "Lutomirski, Andy" <luto@kernel.org>,
        "jamorris@linux.microsoft.com" <jamorris@linux.microsoft.com>,
        "arnd@arndb.de" <arnd@arndb.de>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "pavel@ucw.cz" <pavel@ucw.cz>,
        "mike.kravetz@oracle.com" <mike.kravetz@oracle.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "john.allen@amd.com" <john.allen@amd.com>,
        "rppt@kernel.org" <rppt@kernel.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
        "gorcunov@gmail.com" <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>
        <CAMe9rOpfSccXVWmgK6E0Y0DXC=VX3PpdxXookN1Ty8soeAxrKw@mail.gmail.com>
        <87iljs4ecp.fsf@oldenburg.str.redhat.com>
        <ca106fe1b5005f54525e7a644684108f6a823e14.camel@intel.com>
        <87h6zaiu05.fsf@oldenburg.str.redhat.com>
        <f60f1138813f850d52dd92bc6b3df067c021a197.camel@intel.com>
        <CAMe9rOpVUwCccRb5DAyraEKO48rix+Xfiamfp_Vc_aHhjp7=LQ@mail.gmail.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
Precedence: bulk

* 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