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 8B108C4167B for ; Mon, 11 Dec 2023 16:26:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1687A6B016A; Mon, 11 Dec 2023 11:26:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E75B6B016C; Mon, 11 Dec 2023 11:26:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E54536B016D; Mon, 11 Dec 2023 11:26:44 -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 D0A216B016A for ; Mon, 11 Dec 2023 11:26:44 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A2B52A07CC for ; Mon, 11 Dec 2023 16:26:44 +0000 (UTC) X-FDA: 81555065928.05.E3ED58C Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf29.hostedemail.com (Postfix) with ESMTP id 83EC7120019 for ; Mon, 11 Dec 2023 16:26:42 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="ByEEFq9/"; spf=pass (imf29.hostedemail.com: domain of adobriyan@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=adobriyan@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702312002; a=rsa-sha256; cv=none; b=cdR20mBuAkwrg9PvE+E6yxCSulCXdu0BJOgUdT24MkebnFzN+zFaROMeDPhvlRfXoO/0Hq O2x8Ojg7nj3nFByCq/fgmJ3M4nizIbbqTKriKoLSIqK8b/2RVCQ+pzVsZHouTNaPOldCH1 OStMyIWz/q3dwrYymo/1RdR+fGIBSM8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="ByEEFq9/"; spf=pass (imf29.hostedemail.com: domain of adobriyan@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=adobriyan@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702312002; 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:dkim-signature; bh=NAIDey4/RJpew1wYosy/s17kDRCEpYHvKTUhWB5Rkvw=; b=GNEAJjGKWso9cPDGszk5JTgWuioyjqMxxV9AiP15SCrkJx0l85TJ/K6QlX1Wi52uYqEt/+ aP1d5+Kq0ODFB0CUdHLzVNTvr4V38EUNgWG+qdTsmJC3EBaqTEiMheoTx4RvjwzD4znddB 9RV88d6CCJ6zs7QlwLl1c/+XO9dBj1I= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-551437d5344so1153081a12.1 for ; Mon, 11 Dec 2023 08:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702312001; x=1702916801; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=NAIDey4/RJpew1wYosy/s17kDRCEpYHvKTUhWB5Rkvw=; b=ByEEFq9/5YJHcurxO7lv3eVxoayklfcNxbW5MMFIGs11tn/fVvuSq71Bci2yDUqqVZ zqN2aY9mpK5x7Nk2xeTAc1NCGbZ1J2LMeEB/vo22hE9/8zH0eWdbKDZCWNVH9f7X6tAs MBmNpPIRbeDArpPrMnn5gOovOceGHMH82CxVHu5gS4q6yCMKY6UOU4ytEm+r4x7XT6xc DH/+iM8kFOPZZzdaaeVseHx4DrIpWztMnLlNZ245qWM83I+VlqQpESfGiPsj0FEYXh36 qbNCawCtRnDUxryWLWbyOkpjPpS6kSeOJv+3oUPYKVRoR4R+fOxkLpcjVluxBCv27uRd tYDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702312001; x=1702916801; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NAIDey4/RJpew1wYosy/s17kDRCEpYHvKTUhWB5Rkvw=; b=nubsoHveQbPmj7WPEuQleChPeaSrV32iRkVlxEQigIpl3lmNZE2WglcAA/Zh2UazwL gztMJKjy6T88TQEFJ3wno7vznVIlyA+OzrRSiHrlTrBVqJl0PEspUMnLU9BuLIBf+DFK iiCYvDzgb+rg6GnlPkkPiefCWu1ZdC4pXWI1whLTsA0/eUdp/QNoIV06c8vE/vGiqRKY qQJO5wX1a8ITJzGhRIF1gitgSg0ooPXGRJzQpELUuo3DG0sDH9dJdSHhHq8rJQ7lsD8C BcyXK633JVXOzU2eRFh+F992MiAn2YzMrnhPkG8oathQpzJsc3U6tAN2UVpNcs9h7aTX 4BNA== X-Gm-Message-State: AOJu0YxFHr5NPXqaTqScglh3rV7DGgMyL8ccs6NnhgOQ6gxvGX9ibLXE NCcTYDOn8pdy3QSNkTqdcA== X-Google-Smtp-Source: AGHT+IE8SA+Zfu0wxgDjSfpcJ+DvSrQvEKDAlLcq6l3Sc9LzND6SYsZ2l9I7s4JZ3N/dxoOKrwkucA== X-Received: by 2002:a17:906:194a:b0:a1d:731b:1ae3 with SMTP id b10-20020a170906194a00b00a1d731b1ae3mr2266030eje.100.1702312000634; Mon, 11 Dec 2023 08:26:40 -0800 (PST) Received: from p183 ([46.53.250.155]) by smtp.gmail.com with ESMTPSA id vw11-20020a170907a70b00b00a1cbb055575sm4993429ejc.180.2023.12.11.08.26.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 08:26:39 -0800 (PST) Date: Mon, 11 Dec 2023 19:26:37 +0300 From: Alexey Dobriyan To: "Eric W. Biederman" 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 Subject: Re: [PATCH v3] ELF: document some de-facto PT_* ABI quirks Message-ID: <5c50e975-4e57-4feb-8f14-036b7937f350@p183> 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> <87edftbr6d.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87edftbr6d.fsf@email.froward.int.ebiederm.org> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 83EC7120019 X-Stat-Signature: ufxpwty35s48urgccqtr7tinkjmo31oi X-Rspam-User: X-HE-Tag: 1702312002-199821 X-HE-Meta: U2FsdGVkX19cUUi+Q1Ao8+r3iUYYRXHj1ZoVxU3ECRoufXlDwsvI7a5LSK9JdZMqiWNIfE2m09Uwcvu+b1SA5xsaEP/bR8jpiZrgJsKjqViMYiBzQNpDLnM0s7mK2ZqzAD68vlJ8AVzsCfYOQeKK5ps9hW9FnoofzbTlYjvlbCF9pDkU7JDxCeRxEFSfshUTDxnSw7CQlEu/1TZY7HO3Qk2Jmsm76zzM/tnTMohF+kPqA059XbwEmnFWjr+SM7k22Etec23VqwAZsVu++lrPMruqMF0UoW3ddAWkHku6B7pJq+F9rsb/CapkiJ/S5Wf0Iwb0zydb62tyRSZUD2AWqWMrOJehdQoiY3CPV5Q+BEEMZUB8mN80LYIIjNkafRH2A0+FmjID5UHEf91b9eiMoN7MfqpoN9d8TkO8bzF5JpQxZfiaOs9ZrmNtjdUtyA4yKVB45RZ6mbvjo7tavsbrfnQLFwbwJtcXIxqDcbHr02OdaBhruDJrGO7KPka6Ptc+vOz8rRe09X1q6CVLI7eihEdiO9/miLzFLy7iVMe7CKIXDL+d14ojaEvNIzNmRd415j1BoHK91uXvyuuN6FClQZNy6UfZSsmMBcnUgpug1XwvYtl8smxDavqpXupTC0RrIEKMQQF1bh9nuRi1hhFRmePMsIW4G0W/Qb1jTDmJyDwyTf5JIhqJ+4AUCbJSQQ57xVVs5+1ebq5uQydWXJS0Zjo9tcYuQH/FerOJYS9r8bmdMFPecAQ9vTxWw51URZ6AmpdlJfcdvvltbBVBAlkOFyZR2kQ83UR4+xTIJnxfRZ1qT8zAZjRDhV7yo0hK1EBC9ukB/AIyeFDmF5WshznBdx0wTbdT6LV/u7LpMEmgkNVC6TpZsrwiPsO4edhvJo7ZIN10dOyaepe8mnRgLVZuQjchj4GPkov7zlmkXfX2CmtCA3WFsmm5XrQGKc5Jn0FNbsNt0aqgMykXmJYK3JK LtM4+0PK waQpJ/eOs6VM3G96Xc0Ci43RrACdY0wVa15UFtI8W/R1dCg1PfB6Cw79YMAE+WAYp1Zq1yS8OGYzlHJDUWL3E4OuqOjPSzgZqI5dWm1t7uMH8HJU1efc5mGKbqcNeVXPPyFbMWbqlN+lU9A9pnQW5roFmqBKjc5WV6u01uJZd1X9kQJnKBwT7Tf4gAJ1FFmCUNOPX3GGBPrWIirlDHq3JQzoe8eeXyKhir1mmkEd7K1FAYct/BYXu7xj5tlRpn261qfvRgo0WN+7eoGCvRSR1NgPs92vRtWFhHgyNxl6UFBkyAYGuTcFHUkCbo+n54FkIBjtDrkVZLRwjPuhxMEyFitPTHP+jHJdf7oBHFzI0oKjlGGToisYwe2YZvhqFQaak0UC8nNwjOiVCA2UYns1ymJppnK5EzanJKle7NF9xwbeEbc5L0Aq68gjpUBr5mgqf34kmsxdOxt9/Wav/LqB0ZFdWzmq+tHIsoA9DoboSses4++AdJirNTE8xTg== 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: On Sun, Dec 10, 2023 at 04:58:50PM -0600, Eric W. Biederman wrote: > Alexey Dobriyan writes: > > > On Thu, Dec 07, 2023 at 09:03:45AM -0600, Eric W. Biederman wrote: > >> 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. Ha! Non-overlapping PT_LOAD segments is reasonable requirement (why would you have them?) but it was reverted. > 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. Branches will evict other branches from branch predictor. And it is always more code. ELF is very rigid format. E.g segment headers can overlap everything else and it is not a problem. Overmapped PT_LOAD segments aren't a problem too (for the kernel). These things should have been rejected from the very beginning. I'd even argue kernel rejects too much: elf_entry = e_entry; if (BAD_ADDR(elf_entry)) { retval = -EINVAL; goto out_free_dentry; } Why even check? If e_entry is bad than process will segfault and that's it. elf_ppnt->p_filesz > elf_ppnt->p_memsz Again, why check, just map the minimum. > 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? I read ELF code too much and noticed that loops are slightly different, that's all.