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 23979C7EE23 for ; Wed, 7 Jun 2023 21:40:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA3008E0005; Wed, 7 Jun 2023 17:40:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2D168E0001; Wed, 7 Jun 2023 17:40:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CDDE8E0005; Wed, 7 Jun 2023 17:40:13 -0400 (EDT) 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 785048E0001 for ; Wed, 7 Jun 2023 17:40:13 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4A90F1405C8 for ; Wed, 7 Jun 2023 21:40:13 +0000 (UTC) X-FDA: 80877270306.26.93CFC3E Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf12.hostedemail.com (Postfix) with ESMTP id 3D90D40017 for ; Wed, 7 Jun 2023 21:40:10 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=sMjiF6MA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of ansuelsmth@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=ansuelsmth@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686174011; 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=lmy4XW07oKHOzK9aUKxDjGz102EX0NciX9ngG/h5Op8=; b=08EHb1ZH4CaqWTkEK5G3FGq8Bph6QVNdh7l+YB9wLUF+BLaWUM1zVg3gZwnI/j8Q/lq7Sr BVntFGffW3BnrYY7JA/ldUTrnpdcn2qgH+Vs4SmQ9ASVehxLw18xAor01e+Vdm/JukLzuZ jowrFGtY/sm+L2AvOjZgFCOlMebLPfw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=sMjiF6MA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of ansuelsmth@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=ansuelsmth@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686174011; a=rsa-sha256; cv=none; b=P5V+34RMF44gwljw0LSO2kHf+zYa/8T7d5pVtGprfY3PQmOGnqfo3Gb72o4UeLJ6Buj6JO DchH+STpenIB52/EWasRPJZJE2Lb0FVCxXHxIO7OvTBg8zVCVMuzfuRUvcmoeRpu1/hpIB rjuLglDLkycNrz69F+u252Y/gWXmG2c= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-3f735259fa0so49554045e9.1 for ; Wed, 07 Jun 2023 14:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686174009; x=1688766009; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=lmy4XW07oKHOzK9aUKxDjGz102EX0NciX9ngG/h5Op8=; b=sMjiF6MA5LBXfcs4yX28hE18P801iKcAwW0xcFksygw4rnvT+zL5KGzA3oLFviaKul SXLDKHuPAh1qrChJafS0iNwbqEs068eawutnLQI9B/sZFGEHB7CfiAzmx7UbtXm+EQQP l5JlHfR3Zugj5hGqVy5FH/hchB+NE/DoeKYNvYT/g1yR20BIIcF/mshlFGni7hiYnaCt dSalA2wX/xqm1OYrmsDZ73HEArh8+lGWNSn2xQ1IE+5Lt+R/hRhMJR8ZSkphENy/MHva jPC81a3SamB5Cb5qUMc0Rskal2S2GA7+lI1E6DQlweIk36WfS4hHnAJOyqoTPLrnmemC Yn9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686174009; x=1688766009; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lmy4XW07oKHOzK9aUKxDjGz102EX0NciX9ngG/h5Op8=; b=FLqwnhaAhdl5hMzA+OsPoQNnk9iTbe65GtZi2vmF9/vYMdyOQeXe6EP9/nOmIi897W gno2JXlbdfbBE+Fc0ySI4IPObJs3v3nDeDtyPkTuXcXgj0vZpI/Gk5nOooAgnKP9pefP lMU/So/LtX4Exjkju9yQZ40adi9mXHGjCCsOOSHA8qsKPFfUOWgPWF50TAsKw6JCAOFc YEvTddN62EVOXN12C/y/H+FwtXqsWYrac2ZjYYk0dqGcVs0a0kqJnfEbecCmpWU7mtBS zSvGA5JQUTRDQuXc0MnotaQeT0UwIl3r8SJGPQPB24OztsxB/1VIKWr5AnfMRAthTrng 6Hcw== X-Gm-Message-State: AC+VfDwdUI8Uv3fRSarPUwpcgMrPzBczWZLPOjwDqwSsNno7fySo7NfW IQYcMUVXw9IqamNhIP3q2M8= X-Google-Smtp-Source: ACHHUZ4PWSrnMRmLSHjyewoXrXzTcg5ud1vYOcwQKJA99JC8o6Ria7mVmbfERcv5Q9z5T0bzHgQATg== X-Received: by 2002:a05:600c:28d0:b0:3f6:143:7c4b with SMTP id h16-20020a05600c28d000b003f601437c4bmr8370899wmd.6.1686174009205; Wed, 07 Jun 2023 14:40:09 -0700 (PDT) Received: from Ansuel-xps. (93-34-93-173.ip49.fastwebnet.it. [93.34.93.173]) by smtp.gmail.com with ESMTPSA id p23-20020a1c7417000000b003f6f6a6e769sm3230521wmc.17.2023.06.07.14.40.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 14:40:08 -0700 (PDT) Message-ID: <6480f938.1c0a0220.17a3a.0e1e@mx.google.com> X-Google-Original-Message-ID: Date: Wed, 7 Jun 2023 20:31:58 +0200 From: Christian Marangi To: Kees Cook Cc: Alexander Viro , Christian Brauner , Eric Biederman , Mark Brown , Dave Martin , Catalin Marinas , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] binfmt_elf: dynamically allocate note.data in parse_elf_properties References: <20230607144227.8956-1-ansuelsmth@gmail.com> <202306071417.79F70AC@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202306071417.79F70AC@keescook> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3D90D40017 X-Stat-Signature: o7zj5xt7uqypgnjkzany1e7ma5zc6dkz X-HE-Tag: 1686174010-279415 X-HE-Meta: U2FsdGVkX19us+x4bdlwP68Kr13di1BR1ilS8E2wwLN1f360L8ChsjaY/g4cjpUGvsupUCUpCALNLK1dh+HbL+qBlmiYxCxeoXDbpu6WZJMtuDF015V2uufGY1Ynlotw+H5H3+tYcn1As/L5U+KeYuWRq24R2RAq+i+zXWsPZfEN4OYW7xKFQaM9XxOVtVWEtXlksLcjHi1k4Y2+Wttm7FthTZs/PBY1rBaXBSmbXnXrUJOxO9NZWJ/tmoH8wpo+JDvrg313l1RPo15f/9lvfbL7H4K5d6pdyZ2W6a0T6uoOQsOKvokTKJ6RVazDfgmNN+CQDVMtAGPqSjiMHiaR/Vqq02JVUV8lUGaQtgN2M6Cna/EhW/a0Ul8UQgulRj6PxSBBvHypXRurGUPue1oFn8NDxmdS8g+UMPp3C41DeG7H0SUj3ApJ/heCD0DMIUPwsUuG2gq2FcG+MXLHHngTp4uaC9JCdatRK6PC3kTw6MsZ8lrrRRWIL39L/RD4duy5ygS24o/8LPN7Qc5d15bjlj2pYxW0uFZ97ywUyejRHAf1r2GCTndPX44+TC3pOa0NjffjNuvpbHpVSjxa41Xjm8by3fnM1pXzou/m+GY7W9BGayeWq2u2VRVuR4mLoSeIS6uGdfUQXWYBz3DxB3lF8SGp+laS+f4Eqd/iwTHZIFbtkqMMYAE9tOuo+r5yUgZqPjkCnMzaNIKU/f7LWUguTM52XYiGNX4ArFewN71EwWiNwxvkWxOojFGa3yGt7LXCEdjJkcEEOkR3q4sB5k1LEWdueI/Cyy8qG6CMvokR5UtdX3kU0urmt05oAvm7UvdkZX+zMfsrZWU+eR36g5D4vQmlLueHLlKTTbV4zjyPnhIGgUc11z4YqLZDGCMaqZZ9ZYFXTBN4lTr9BrXbDgTXqzw5NxXgAwOCd58z3saQI7cO9fVrWuogqBUW9ZuMZNrGr8WrrSEjujSAkx9d0ta 7JuNpVIA WPISBJ5D/M+d037NKAhusziEkJWkADdEVUxYdOb7+CQ+k3cTlYlvEvu7UsTTG3wIAJQyyIpqQeyqqj2Xtcw9XN0Q5lYmBdUlx0/INQpaQM4LBGKSTI6WalvXOsEjrXkMUf3PuTD+TAyq6cn0NmbttGb0CQc38rFIc8E+Z8VWQDYypWP/NgeJd32MxTXGhmWsbF54JHe7LBEd5fKNQZwbcqo2UrpbirfcdokFVjx3oh2/jhrXtAT4Jv+8wAYGqQ194vRRm3VlFfONmIAkXu0yPGWtLxFKMDoExzr3Y9QJGS+dkFQXP2a+hRfJZgihahT1zQQJEdke+T1rQ9CnIzKaC3IxCwSfdWsXYSit3hrIRkkRxAAN1LzM6J0XMzidhFF2EHKB048nauHzs3UM7D0iKEiZNcrXJoAqNuv4ieE71YYyqOBSzXtz109tk/g== 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: On Wed, Jun 07, 2023 at 02:19:51PM -0700, Kees Cook wrote: > On Wed, Jun 07, 2023 at 04:42:27PM +0200, Christian Marangi wrote: > > Dynamically allocate note.data in parse_elf_properties to fix > > compilation warning on some arch. > > I'd rather avoid dynamic allocation as much as possible in the exec > path, but we can balance it against how much it may happen. > I guess there isn't a good way to handle this other than static global variables and kmalloc. But check the arch question for additional info on the case. > > On some arch note.data exceed the stack limit for a single function and > > this cause the following compilation warning: > > fs/binfmt_elf.c: In function 'parse_elf_properties.isra': > > fs/binfmt_elf.c:821:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] > > 821 | } > > | ^ > > cc1: all warnings being treated as errors > > Which architectures see this warning? > This is funny. On OpenWRT we are enforcing WERROR and we had FRAME_WARN hardcoded to 1024. (the option is set to 2048 on 64bit arch) ARCH_USE_GNU_PROPERTY is set only on arm64 that have a FRAME_WARN set to 2048. So this was triggered by building arm64 with FRAME_WARN set to 1024. Now with the configuration of 2048 the stack warn is not triggered, but I wonder if it may happen to have a 32bit system with ARCH_USE_GNU_PROPERTY. That would effectively trigger the warning. So this is effectively a patch that fix a currently not possible configuration, since: !IS_ENABLED(CONFIG_ARCH_USE_GNU_PROPERTY) will result in node.data effectively never allocated by the compiler are the function will return 0 on everything that doesn't have CONFIG_ARCH_USE_GNU_PROPERTY. > > Fix this by dynamically allocating the array. > > Update the sizeof of the union to the biggest element allocated. > > How common are these notes? I assume they're very common; I see them > even in /bin/true: > > $ readelf -lW /bin/true | grep PROP > GNU_PROPERTY 0x000338 0x0000000000000338 0x0000000000000338 0x000030 0x000030 R 0x8 > > -- Is there a way to check if this kmalloc actually cause perf regression? -- Ansuel