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 87FFAC4332F for ; Tue, 14 Nov 2023 16:11:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B3FD8E0008; Tue, 14 Nov 2023 11:11:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 164C96B02D9; Tue, 14 Nov 2023 11:11:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02B488E0008; Tue, 14 Nov 2023 11:11:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E487C6B02D7 for ; Tue, 14 Nov 2023 11:11:55 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BCF63C0B31 for ; Tue, 14 Nov 2023 16:11:55 +0000 (UTC) X-FDA: 81457050990.17.6DF5405 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf16.hostedemail.com (Postfix) with ESMTP id 8637D180021 for ; Tue, 14 Nov 2023 16:11:52 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf16.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699978312; 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; bh=tHXIfeS5qdcZXQnN7CMybfJSbX2aDIfK9UpsQ54HiXE=; b=YKPaQRPdSNUPrn01Fsk+6z+3hEWUxBz1mi8+ampM7lh2857K48zBCHkTYXMgNS7GqjOxMz Al+Q6ETngj4AMV6twp9C5Vh77MeKcCZ+rmFX+Qdv3H6qgGsFMMsq51QnlD/OVQ+rgV6z8r yPcwdfXglDryPpbHm1Fq2/lrT7spBsE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf16.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699978312; a=rsa-sha256; cv=none; b=aLgETihjdFegAzJSdCzuNuyhKiQyarI2L+D0fMeORXzTBV8hnp+OYfK14jJ7cGc9VEpFld mv1sXERgR8xPub4P8SOeYJE/n/pDh6EPUA8rnHnMTr20NQ8JzohN9263TlA29YtuOxqeYs kSdB0bXhwtfBHPqvkfvh9UpBN3/Jz/w= 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) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8637D180021 X-Stat-Signature: cmftog461m7c1focmgazqmuo1aot5kuq X-HE-Tag: 1699978312-204493 X-HE-Meta: U2FsdGVkX1+drGdLuni7dV/Q37Oiy6I3sze5CoLWceEMYnKYv9qEHz2S55krRqMZtGccFy/lTc+yHA+Eph34Ou2O6akNID3l5Y6p87S0PhPj/gvu6tVcXoQ/DLEAk02ZTpimn0aVXgewOa1XV/OrnDr+mVZSGX2JKX5J5S4qHHXjhsLUsHSYi9ysSlwRyWqYUX9UVBBRHjQvFr6t4qP9EErXceU7jvg7EDbEpZ+nbks7eybGN2ZbSU336vvUicOsudfIIpDlDODwWlgpstjnQ/IL0qLUX9ZtLNzs5yvSntf3VMY6qEXZtSkb1Fhbn34z5SfhWvBi6S2FuahWe7xjcrKPpU+qM9zlaBWnX6pr7rce1FWIx0GvMsluDMDYAbrJXQGnyisxHWejYzFxvcN8kqTq3M0n3lk1tElgGMN3dz7B2McKM0dfU2E+SR0UluoFgVOVfDaaUkCSMjZ486WA0ve/mElrcQ6/RWhDPrliT+JLmmxuktPQsKSAgcI/RL6JYttH1QOjTSQBEdSe8rA5+pMVCOlJ6Tvr4qnbgXC/fHE2sTvWX0UKpo37yZI+I3euoXfdRf6V2sKwbLomTRJZyEFPJn82nx6u12339gRAkLRIl5QzQixWNlMAIR8rGlCg5aZU+S8Kl3pMaItqOaRiMSlS26Z0v73tW44qVItaa7zi+nkGJgWVrGxoUT00P8W8bOjkDp3aJ1+49i3NtTHyOmBn9Q9lA6uc9rr6xJiQDM0nBY2NOQA2TXlIa4Np8p6rTf0T0K2P6iydcsVHbY3S+wwYCAB7+dsyP8NZkoQ4Tgpu5yyahjITDrIIeyI0JkWWR6l3mD4h6R+IW+QHo5jhbDMUlEX/hXEMiPiO2DAKLA2AB0ibtmqITS2tySYoJbT0xug3ZWJyWim1BF76dogCsIgR0GzUN0XXzAa/V6a4JuYFcqXL7nzOKFDmWNX5XrQX7JGHs8YrNeABSRVDtiz 5/t2nbCd G+Z6THMJDmX67Eh218QhHb5QyfWewuBUCWQvZ+mCJmeJfvATk0oKrqxB0ffAJKi2QOuldKAyL7FuOkOgvOK99ctxFrGj7yZMkVjcHujQICNEu9oesiecrJZM7nCBCF/aJ/yq0MoKGbRpfEnEg0AEcymYgGhx81zoLUptI7nNBgCo8tEzen64DJIbfiEmr9V4GSdy3vr8isubzP5Wb3g2awD0bQFPxWK1LATlJ 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: List-Subscribe: List-Unsubscribe: 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