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 0E7F3E71D53 for ; Fri, 29 Sep 2023 15:33:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233656AbjI2PdM convert rfc822-to-8bit (ORCPT ); Fri, 29 Sep 2023 11:33:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233517AbjI2PdL (ORCPT ); Fri, 29 Sep 2023 11:33:11 -0400 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E737B4; Fri, 29 Sep 2023 08:33:09 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]:59108) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qmFUK-00FzWn-ET; Fri, 29 Sep 2023 09:33:08 -0600 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:57062 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qmFUI-009b5s-TR; Fri, 29 Sep 2023 09:33:08 -0600 From: "Eric W. Biederman" To: Pedro Falcato Cc: Kees Cook , Alexander Viro , Christian Brauner , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Sebastian Ott , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Andrew Morton , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org References: <20230929031716.it.155-kees@kernel.org> <20230929032435.2391507-4-keescook@chromium.org> Date: Fri, 29 Sep 2023 10:32:59 -0500 In-Reply-To: (Pedro Falcato's message of "Fri, 29 Sep 2023 13:12:13 +0100") Message-ID: <87y1gp6llg.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1qmFUI-009b5s-TR;;;mid=<87y1gp6llg.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.168.167;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX18dXVfN1YAEePbYpFJoWWbpYNcqcNqjTNI= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v4 4/6] binfmt_elf: Use elf_load() for library X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Pedro Falcato writes: > On Fri, Sep 29, 2023 at 4:24 AM Kees Cook wrote: >> >> While load_elf_library() is a libc5-ism, we can still replace most of >> its contents with elf_load() as well, further simplifying the code. > > While I understand you want to break as little as possible (as the ELF > loader maintainer), I'm wondering if we could axe CONFIG_USELIB > altogether? Since CONFIG_BINFMT_AOUT also got axed. Does this have > users anywhere? As I recall: - libc4 was a.out and used uselib. - libc5 was elf and used uselib. - libc6 is elf and has never used uselib. Anything using libc5 is extremely rare. It is an entire big process to see if there are any users in existence. In the meantime changing load_elf_library to use elf_load removes any maintenance burden. Eric