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 C602FC4167B for ; Sun, 10 Dec 2023 22:59:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 071BE6B0078; Sun, 10 Dec 2023 17:59:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 021246B007E; Sun, 10 Dec 2023 17:59:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDD676B0081; Sun, 10 Dec 2023 17:59:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C82676B0078 for ; Sun, 10 Dec 2023 17:59:20 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9CF2540639 for ; Sun, 10 Dec 2023 22:59:20 +0000 (UTC) X-FDA: 81552426480.08.E40C57A Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf18.hostedemail.com (Postfix) with ESMTP id 32D6F1C0015 for ; Sun, 10 Dec 2023 22:59:18 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf18.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=1702249158; 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=Zv6H7Lpf+tWMSbUJDcl89UEHPvF8crlWY8DKPxgPCQ4=; b=cKBbn3rDq2tytjULM5TVNz3WFAY8JxVtmIjGwJ1qiMUa2k9ZE2bqNazUNfcOiOzyHEeOOt p/544vlwkpSq5rSPcnmciJYoEgsaiuFGD1KdSRBwQkoBRAWFWXdttYL6agSf6D8Ey46ljL d47St5PkkJAd86SrjO0bQE6GHV9+DaA= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf18.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=1702249158; a=rsa-sha256; cv=none; b=ho1iciL6i5z45dcqZk6Bjj8DLikiXCXkgyA4Me7HVOfrOE4vmBOpKLtfVrw38PB6VOoEJF 1Iw5Q39k37aK7N9X6bHXGbNxdvZbUMtpudP2Soim0HBFUCSCJmL5+207lFbac+QFuf2jnl 2K7WX5S9PVwdPPpELbrHp5cLrD5U8sQ= Received: from in02.mta.xmission.com ([166.70.13.52]:52474) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1rCSlV-005rO9-G9; Sun, 10 Dec 2023 15:59:13 -0700 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:53806 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1rCSlU-00CZ52-9k; Sun, 10 Dec 2023 15:59:13 -0700 From: "Eric W. Biederman" To: Alexey Dobriyan Cc: Kees Cook , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Randy Dunlap , Bagas Sanjaya , Jonathan Corbet , linux-mm@kvack.org References: <2acb586c-08a9-42d9-a41e-7986cc1383ea@p183> <87edp7jyu4.fsf@meer.lwn.net> <88d3f1bb-f4e0-4c40-9304-3843513a1262@p183> <202312061456.2103DA1@keescook> <874jgugilq.fsf@email.froward.int.ebiederm.org> <57f5aa9d-79c5-4f65-b90f-204600edfb80@p183> Date: Sun, 10 Dec 2023 16:58:50 -0600 In-Reply-To: <57f5aa9d-79c5-4f65-b90f-204600edfb80@p183> (Alexey Dobriyan's message of "Sun, 10 Dec 2023 14:45:18 +0300") Message-ID: <87edftbr6d.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=1rCSlU-00CZ52-9k;;;mid=<87edftbr6d.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.168.167;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX18nVuD+PRK7RFCBnf6/BI6snLlX9HWTiUQ= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v3] ELF: document some de-facto PT_* ABI quirks X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Rspamd-Queue-Id: 32D6F1C0015 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 9yps3w9g8trfyarb6uprmx1m7jztaws7 X-HE-Tag: 1702249158-433660 X-HE-Meta: U2FsdGVkX1/ur/YOv/3oYv6WSOsOnRsGdcGGX8frDrnzvsotObq5131++SWnMVfOLDHOqnz4S37yg7RIAQKn8zkvXN+mDrRr9oVVwgtptmJsdgbMyUxzla3YelmcZZ9lVsKq/tvJVxnRGfRI9FDYtI377fTgHmgE+c4U4fmQ1xsIecUTswLFb3V2OL3bV12y5yAqiOcestRw9HOplXYt8PS6lRqXv01ER34o6QIyxW3SHAPsTds8ZeCqaYzyoP2qp0D+X2mTwjXDTU/0VBcfTdjRBJickNCfK5dgVcAJc7Ow4KkEFmQgwXOGttD6UjtFcMAh5FHPAw6jWkYXKye25BZBRMd2ISaigZeigw87D1d3JPwLPIuK3+uQYxiBniQP19e75Zy1mZsUrrq3wFXqlUpgSmjlUL31acIei2SykKiW5IZxZS+1jm2v2QeTyThqPa+8g35e8NvuJSruHRezDvjUKOiP5NeZqe+U0Ty7lLACmDnxFXkPZpugg9z7dSj7jRplbevsj7syvk2TYy/oJ8Uk6E8L8B3LLzL6EGKNWBYVpRo5HUIDFPreiJjTUsyoYQKoS4zmnRNRdLkMs4wKRRu43jdJBZM501E6mnKD/UbbjRz4nqS4uBfP60OkubBFtDRixvhP96vZY2Y8z0WhdfE578PveipyO9052yUXobQqbt4zm7R01Y+8X8d9nHoqlsTX4IbAFW2l2PPdr9lxNWPryCReQj9zpWXpWnsXSizfuakUGY2D4znakuxB1XZudQ4DeU7T6rjRdviU3SQg6l36iTAx2GjASpd2pfGkXI06oLmDoXkMOkqcVbUBsQ3/IlhpUsiROfNNiEQbg4SJAuhmpDtEJ94tv8Cmtlp6s2QJKNc4RRBLj6XQ/g99TiBMJVGB620V5DFy2MmeLjj3uKsd5xk+PrH6xfY+7mQZ0aSciCISgBLUb7qq5d69LBSJ+f8aMXd5HhPydiBUqev bBHh+uQ4 Syd2Qjja4OpWjjSSnF54HZHANMWegIFpbJ0xQxUNaUaxCKv6J4iXqRyGvDntlxbjivUOWqrTgtvM26UstVWWlNdPpFQ6GT1n0NZjQTk6TQXIjqcoido7r+99M/Yp5M7apxEJzd894D5iu451nhNycCrAJYw== 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: Alexey Dobriyan writes: > On Thu, Dec 07, 2023 at 09:03:45AM -0600, Eric W. Biederman wrote: >> Kees Cook writes: >> >> > *thread necromancy* Question below... >> > >> > On Sat, Apr 15, 2023 at 08:37:29PM +0300, Alexey Dobriyan wrote: >> >> Turns out rules about PT_INTERP, PT_GNU_STACK and PT_GNU_PROPERTY >> >> program headers are slightly different. >> >> >> >> Signed-off-by: Alexey Dobriyan >> >> --- >> >> >> >> v3: move to Documentation/userspace-api/ >> >> v2: integrate into documentation build system >> >> >> >> Documentation/userspace-api/ELF.rst | 34 ++++++++++++++++++++++++++++++++++ >> >> Documentation/userspace-api/index.rst | 1 + >> >> 2 files changed, 35 insertions(+) >> >> >> >> new file mode 100644 >> >> --- /dev/null >> >> +++ b/Documentation/userspace-api/ELF.rst >> >> @@ -0,0 +1,34 @@ >> >> +.. SPDX-License-Identifier: GPL-2.0 >> >> + >> >> +================================= >> >> +Linux-specific ELF idiosyncrasies >> >> +================================= >> >> + >> >> +Definitions >> >> +=========== >> >> + >> >> +"First" program header is the one with the smallest offset in the file: >> >> +e_phoff. >> >> Confusing e_phoff is the defined location of the array of program >> headers. >> >> Perhaps the "First" in that array with the lowest e_phnum? >> >> >> +"Last" program header is the one with the biggest offset in the file: >> >> +e_phoff + (e_phnum - 1) * sizeof(Elf_Phdr). >> >> Ditto the "Last" in the array with the largest array index. >> >> I nit pick this because it sounded at first like you were talking about >> p_offset. Which is a value contained in the program header entry. >> >> >> +PT_INTERP >> >> +========= >> >> + >> >> +First PT_INTERP program header is used to locate the filename of ELF >> >> +interpreter. Other PT_INTERP headers are ignored (since Linux 2.4.11). >> >> + >> >> +PT_GNU_STACK >> >> +============ >> >> + >> >> +Last PT_GNU_STACK program header defines userspace stack executability >> >> +(since Linux 2.6.6). Other PT_GNU_STACK headers are ignored. >> >> + >> >> +PT_GNU_PROPERTY >> >> +=============== >> >> + >> >> +ELF interpreter's last PT_GNU_PROPERTY program header is used (since >> >> +Linux 5.8). If interpreter doesn't have one, then the last PT_GNU_PROPERTY >> >> +program header of an executable is used. Other PT_GNU_PROPERTY headers >> >> +are ignored. >> >> A more interesting property to document is that PT_GNU_PROPERTY must >> precede PT_INTERP in the linux implementation, otherwise we ignore it. >> >> > Should we perhaps solve some of these in some way? What would folks >> > prefer the behaviors be? (I like to have things been "as expected", but >> > it's not very obvious here for redundant headers...) >> >> All of these are really headers that should appear only once. > > Yes. > >> Quite frankly if we are going to do something with this my sense is that >> we should fail the execve with a clear error code as userspace should >> not be doing this, and accepting a malformed executable will hide >> errors, and perhaps hide someone causing problems. > > Maybe do it for PT_GNU_PROPERTY which is relatively new. > >> I really don't think having multiple copies of these headers with >> different values is something we should encourage. >> >> It looks like -ELIBBAD is the documented way to fail and report >> a bad file format. > > It is obvious you don't know how much will break. My assumption is frankly that nothing will break. My quick examination of userspace binaries suggests that nothing is silly enough to duplicate such headers. Do you know of a binaries in userspace that duplicate these headers? Without a documented ordering arguably anything that results in these headers being duplicated is already buggy, and broken. I can think of no use for duplicating these headers other than as some kind of gadget in an exploit. I don't see how such a gadget would be useful currently. > >> For PT_GNU_PROPTERTY perhaps we should accept it anywhere, instead of >> silently ignoring it depending upon it's location? >> >> I thinking change the code to talk one pass through the program headers >> to identify the interesting headers, and then with the interesting >> headers all identified we go do something with them. >> >> Anyway just my opinion, but that is what it feels like to me. > > _Not_ checking for duplicates will result in the simplest and fastest exec. > which is what current code does. Given that I/O is involved taking a pre-pass through the headers is in the noise, and it might even make the code faster as it would prime the code for the other passes. The fastest of course would be to have the elf loader only look at the first of any of these headers. What got you wanting to document how we handle duplicates? Eric