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 8C840C021B0 for ; Thu, 20 Feb 2025 01:36:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1440B28026A; Wed, 19 Feb 2025 20:36:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F51C280257; Wed, 19 Feb 2025 20:36:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F257728026A; Wed, 19 Feb 2025 20:36:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D4283280257 for ; Wed, 19 Feb 2025 20:36:44 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 86EA8160917 for ; Thu, 20 Feb 2025 01:36:44 +0000 (UTC) X-FDA: 83138608728.30.F7A7BDD Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf08.hostedemail.com (Postfix) with ESMTP id E6A63160006 for ; Thu, 20 Feb 2025 01:36:42 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mvOfCIKx; spf=pass (imf08.hostedemail.com: domain of kees@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740015402; 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=C67h9GV2EutMrm3SZmNOIWY7w5lUYLpiExducNUKfhU=; b=FI0IUrjYPuXaCN/27/+VaVTQ6pot+cIq1+RTtt48FezgQ5Lkz1qJ2psN9/Sy7sCCOL3ObB RUkECzugTOdI/NTlZszvOWdaJ7oP3Zj5ZtelSzgjtcJhRddgNPMaZJYZoW8D9FkU4MWyFG Uz57SEckv4bGBMhFLd5xLUbh7l0XqDo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mvOfCIKx; spf=pass (imf08.hostedemail.com: domain of kees@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740015402; a=rsa-sha256; cv=none; b=LIk5cU+oJv5xI1qbJpvnJwdy2XcnfOXz8sEmDpGQf9oEUUw2LZ12X77blyesi9XmrxYnPI EW3fBOE29jqJdqnfSHK15JWvWn7Gmu9K3bTTyhH5NsjcvX5JEXZCykh5OYQ/0CkoE5djY0 ZADHNbtPnU9u5jDkKIG8Iaxs4SYOBFs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 742A16117C; Thu, 20 Feb 2025 01:36:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88E22C4CED1; Thu, 20 Feb 2025 01:36:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740015401; bh=G7y5fZLYoCEA0WNpfSVGiEZ6Ecj45M7vMtWV4gOanfM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mvOfCIKxl1lj+zRaUv8U9NLsUnIYAcyxAZOgLBlRinINl4IAPXAgCMAtvLO7mR3Ec CwjdWKs6riRCSL1DMi7Zbo3udxyBt7UnFgjux3yCPiKfIzWRtiIgdJjZXSuIOu0pQc xI9XY+tbsnDYFVgtLGEfuHtRnH+IcGQmyNgkn26RchIeXeucScLiggqQQHCqAB8kcz UoWN2trQdGUoMq81xRTXE9JOHr40keD3qaiBMIh/zvrp9iGKkCN9MC33JoSfwfhnfz 8ZdAPNCIwsOoOVsKQ5JCa3TR2OlYgjuGf5WYA99Oa7TLaMqV5IQ1T2fTAQdxU7rwWO 9enxpPej/NULw== Date: Wed, 19 Feb 2025 17:36:37 -0800 From: Kees Cook To: Linus Torvalds Cc: Jan Kara , Michael Stapelberg , Brian Mak , Christian Brauner , "Eric W. Biederman" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Oleg Nesterov , Alexander Viro Subject: Re: [PATCH v3] binfmt_elf: Dump smaller VMAs first in ELF cores Message-ID: <202502191731.16FBB1EB@keescook> References: <036CD6AE-C560-4FC7-9B02-ADD08E380DC9@juniper.net> <20250218085407.61126-1-michael@stapelberg.de> <39FC2866-DFF3-43C9-9D40-E8FF30A218BD@juniper.net> <202502191134.CC80931AC9@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: E6A63160006 X-Stat-Signature: kdps6ix7z7bjbnutrjnb6ucax7663yrj X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740015402-486926 X-HE-Meta: U2FsdGVkX1/E41hNUY2d+yguHahugGYVXvgoo8/oNr52vsx6gUjxlkVrTGlkTWEXNFII9sTswCxqdhTi2ToR9OdoGuVGneL+wYjcqKfSrSrtU8nzITFNHiqRbQHF96i1K4aifh9fRXGHKwFWTvI0Bth+4YfaP4r/IIiDg/CCPPafTaFBiPHO761BnjTC26ssbt0poCWGN/YXWWtggvK4MwQNzdZL3v3FwTwaqwPWmWCa5H+dwQoQY/pk9QqWKz1HotKmK2j9WJUPQ3LDCGJ6nRFjwfQ+iUqJqSr3fljaV2yckWFUQ+bfzEX/eZ3PchWQ5LVubSfj+Bx0bVpphH5dQXZyNYAPE+sVsBu+3LgzyElSroj+e4LdiSuCOTsXwRWqaAl2WwCu8WQX1+QUyK3Wosqgs1BL0UeDKsUjkH3zi/vPiL4e8Hp0ARM5Ra0Chrdq4EvW0smo78kUEG9oMM39Vl0Izrlecel9W9+d667le0GIiKj9sMWn3G9CXkJ1z38n0TWu+yYFOI7Vk8fW2yiwrMZtAJ0fEIIeAah5swC6reyQqDpC/xgUUiH52EzbuUbiQtu9Wkw8QYsMv1nopUVgZmEGqjU4VeP/Z2WU7ld+/ehd2eAxsQsN1CXlcmMC8eADWVBF7RRL9evUEvYl+KegjSzWaMKSal6D1j+Leo/5daAZBzQmf59D8uelPY2i9mt1zwe0079TZxqVYoJ2AfLZJRx4Kavwc15oXJLoBIdPqUkoiB2YigUUK7CQznQ/A/d6gusbgEJ3uedKNI2+Mtof4uhgznLLI71133Xk+wnURpAN1sZvVlxIz5rvhXwPtP53NhvadLgzM1xexoqyCfPGAkvk6DnN0/Dt+QAvIQEyZN8rfKhqSiyN3xrKjgP9/VzKBKQtOekByxj3vV3byhq4QZLgdvdAlOh9gC8/EhUOvpZ77z2IlxjWvA8CGTZKsXX4e/1Qu++nauYzSqu0hxI 6aKlUX3a 2pvM0zmYgYl4OWKCiGqjs3GTvFFxpDjgGy0d8jHJcTX0cCEW7GddwUF0SJm/xql8qec0LGpoYijRZ8PhdP2LeqTfpbo/f5kZIt0r5Cb8nTM5fq/y6e1wTDjpwBqg6qCNs8+yhJ/BiZKwnyAh/znQBDnmyy0rGKNXU70vTWni/6a7L+0PqYuXY5Du/DERqXhpbycPY2nUVowBxLRjrh4iw/foarKTtrsnLirDLIhD5e4UO9ehx/ET1L/V8f20+N4+qrnqrtM2A8p0DjPHyZSsc5ixjIcBM5vZNGifP6VNJAR/k5GJJZm0ASUghsvb07htoDIusgvgDJxKHq2BlZ1/izi8XqMrKzh1rB2fsMtYlwH0FJ24= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Wed, Feb 19, 2025 at 04:39:41PM -0800, Linus Torvalds wrote: > On Wed, 19 Feb 2025 at 11:52, Kees Cook wrote: > > > > Yeah, I think we need to make this a tunable. Updating the kernel breaks > > elftools, which isn't some weird custom corner case. :P > > I wonder if we could also make the default be "no sorting" if the > vma's are all fairly small... > > IOW, only trigger the new behavior when nity actually *matters*. > > We already have the code to count how big the core dump is, it's that > > cprm->vma_data_size += m->dump_size; > > in dump_vma_snapshot() thing, so I think this could all basically be a > one-liner that does the sort() call only if that vma_data_size is > larger than the core-dump limit, or something like that? > > That way, the normal case could basically work for everybody, and the > system tunable would be only for people who want to force a certain > situation. > > Something trivial like this (ENTIRELY UNTESTED) patch, perhaps: > > --- a/fs/coredump.c > +++ b/fs/coredump.c > @@ -1256,6 +1256,10 @@ static bool dump_vma_snapshot(struct > coredump_params *cprm) > cprm->vma_data_size += m->dump_size; > } > > + /* Only sort the vmas by size if they don't all fit in the > core dump */ > + if (cprm->vma_data_size < cprm->limit) > + return true; > + > sort(cprm->vma_meta, cprm->vma_count, sizeof(*cprm->vma_meta), > cmp_vma_size, NULL); > > Hmm? Oh! That's a good idea. In theory, a truncated dump is going to be traditionally "unusable", so a sort shouldn't hurt tools that are expecting a complete dump. Brian, are you able to test this for your case? -Kees -- Kees Cook