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 E3739C4167D for ; Tue, 14 Nov 2023 16:11:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233799AbjKNQL5 (ORCPT ); Tue, 14 Nov 2023 11:11:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233320AbjKNQLz (ORCPT ); Tue, 14 Nov 2023 11:11:55 -0500 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF8FDF0; Tue, 14 Nov 2023 08:11:51 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]:33842) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1r2w0z-00Cbqy-Ug; Tue, 14 Nov 2023 09:11:50 -0700 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:46168 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 1r2w0x-00FFJ1-QV; Tue, 14 Nov 2023 09:11:49 -0700 From: "Eric W. Biederman" To: David Hildenbrand Cc: "Guilherme G. Piccoli" , Kees Cook , sonicadvance1@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, kernel-dev@igalia.com, kernel@gpiccoli.net, oleg@redhat.com, yzaikin@google.com, mcgrof@kernel.org, akpm@linux-foundation.org, brauner@kernel.org, viro@zeniv.linux.org.uk, willy@infradead.org, dave@stgolabs.net, joshua@froggi.es References: <20230907204256.3700336-1-gpiccoli@igalia.com> <202310091034.4F58841@keescook> <8dc5069f-5642-cc5b-60e0-0ed3789c780b@igalia.com> <871qctwlpx.fsf@email.froward.int.ebiederm.org> <9f83d97e-b7a1-4142-8316-088b3854c30d@redhat.com> Date: Tue, 14 Nov 2023 10:11:15 -0600 In-Reply-To: <9f83d97e-b7a1-4142-8316-088b3854c30d@redhat.com> (David Hildenbrand's message of "Mon, 13 Nov 2023 20:16:49 +0100") Message-ID: <87ttpouxgc.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1r2w0x-00FFJ1-QV;;;mid=<87ttpouxgc.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: U2FsdGVkX18A0u86nlnYSNcejSdGhCmXdqM80fiLBAM= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [RFC PATCH 0/2] Introduce a way to expose the interpreted file with binfmt_misc 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-kernel@vger.kernel.org David Hildenbrand writes: > On 13.11.23 19:29, Eric W. Biederman wrote: >> "Guilherme G. Piccoli" writes: >> >>> On 09/10/2023 14:37, Kees Cook wrote: >>>> On Fri, Oct 06, 2023 at 02:07:16PM +0200, David Hildenbrand wrote: >>>>> On 07.09.23 22:24, Guilherme G. Piccoli wrote: >>>>>> Currently the kernel provides a symlink to the executable binary, in the >>>>>> form of procfs file exe_file (/proc/self/exe_file for example). But what >>>>>> happens in interpreted scenarios (like binfmt_misc) is that such link >>>>>> always points to the *interpreter*. For cases of Linux binary emulators, >>>>>> like FEX [0] for example, it's then necessary to somehow mask that and >>>>>> emulate the true binary path. >>>>> >>>>> I'm absolutely no expert on that, but I'm wondering if, instead of modifying >>>>> exe_file and adding an interpreter file, you'd want to leave exe_file alone >>>>> and instead provide an easier way to obtain the interpreted file. >>>>> >>>>> Can you maybe describe why modifying exe_file is desired (about which >>>>> consumers are we worrying? ) and what exactly FEX does to handle that (how >>>>> does it mask that?). >>>>> >>>>> So a bit more background on the challenges without this change would be >>>>> appreciated. >>>> >>>> Yeah, it sounds like you're dealing with a process that examines >>>> /proc/self/exe_file for itself only to find the binfmt_misc interpreter >>>> when it was run via binfmt_misc? >>>> >>>> What actually breaks? Or rather, why does the process to examine >>>> exe_file? I'm just trying to see if there are other solutions here that >>>> would avoid creating an ambiguous interface... >>>> >>> >>> Thanks Kees and David! Did Ryan's thorough comment addressed your >>> questions? Do you have any take on the TODOs? >>> >>> I can maybe rebase against 6.7-rc1 and resubmit , if that makes sense! >>> But would be better having the TODOs addressed, I guess. >> Currently there is a mechanism in the kernel for changing >> /proc/self/exe. Would that be reasonable to use in this case? >> It came from the checkpoint/restart work, but given that it is >> already >> implemented it seems like the path of least resistance to get your >> binfmt_misc that wants to look like binfmt_elf to use that mechanism. > > I had that in mind as well, but > prctl_set_mm_exe_file()->replace_mm_exe_file() fails if the executable > is still mmaped (due to denywrite handling); that should be the case > for the emulator I strongly assume. Bah yes. The sanity check that that the old executable is no longer mapped does make it so that we can't trivially change the /proc/self/exe using prctl(PR_SET_MM_EXE_FILE). Eric