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 DEF73E936E7 for ; Wed, 4 Oct 2023 21:28:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E9B238D00B0; Wed, 4 Oct 2023 17:28:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E4ADB8D0002; Wed, 4 Oct 2023 17:28:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEC308D00B0; Wed, 4 Oct 2023 17:28:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BC7AF8D0002 for ; Wed, 4 Oct 2023 17:28:57 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 90F6DA0461 for ; Wed, 4 Oct 2023 21:28:57 +0000 (UTC) X-FDA: 81309069114.03.F4C1485 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf01.hostedemail.com (Postfix) with ESMTP id 33DAC40013 for ; Wed, 4 Oct 2023 21:28:53 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CI+arBbK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of slyich@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=slyich@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696454934; 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=GOrt1OMVcS1GeLKT3xwXjNRDdAC0gAN5SlUNcwokFVQ=; b=lZZ15U7y0LS4to863PBkDRVy0FxWtDT3e8NdX6DFwrdUVePbi2OrL7y8LXgKw58Y6WhgCl 0Ix0BPVeglLp3I08bcEwfFEhIhHt6YMf+h4TYPHyyCWbMjS2zzfEuTovdzScI7fnhnvwI/ g06EGfdkZINaPdQhyGi8eIdDJf8IvSo= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CI+arBbK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of slyich@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=slyich@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696454934; a=rsa-sha256; cv=none; b=yCQVL34XWD38G0XGxvRKNkj4UjmqkAU7AF8TBMrbbh7+GdBICWELO+nw3j1052BgapZWwh 591n1BezZoV/hQsZwPSvDoX1FmaB2tTVK4zM1epxDbspv3jnXbnvs/WCWtmswc9HL0lw+O ymOReFL2ahLh1MohvVTkfOl8bph/CuA= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-406650da82bso2272795e9.3 for ; Wed, 04 Oct 2023 14:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696454932; x=1697059732; 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=GOrt1OMVcS1GeLKT3xwXjNRDdAC0gAN5SlUNcwokFVQ=; b=CI+arBbKdhczi3p99M3MIygRSUH4Z46k+UkMGmEdt24siYu+XFjNxdrnJLLADbos/H 1DPOloZp/MUimFohH6AfiEtAUTf2ZJPLN3R9ZxqQ5uLC7qZOFOlFKE8hY85ecrd5E4Yj B/kpu6z+zpNSfyL+6bxZnFNTdC1qea/AacnUWTRA9hDS03mtu4lFzCq001hhRWwUPjhP ljmQKj9x4g0Pb1aIjWYlUGE5xkaVyep/xf/SqrszI3HAf34zkz0LU8t4/m3Fz/VIiTR5 N3XqNUDOGZh6Qz/kQIRqFmrf7bLdghejWxK5HMZRxDU/ysI+ANoD7uvbXGT/REnz37AV 9GLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696454932; x=1697059732; 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=GOrt1OMVcS1GeLKT3xwXjNRDdAC0gAN5SlUNcwokFVQ=; b=FVC/XQLFmrH31XnlsLGgO9Kv9V+5DiweCwwzqgCn9hmoHVhr5e7hAhvDJ46JjsRxfR oc6qY9gRhStq6KzgRAPVnOdJLV5xGiG6XJYB4j+jctXujZAOVRrrmrC+ARWXl2PPSP23 1SNJIqcksc5lZM01+jD6YpdGHllb+eDczLymGSfY7MOy70VBFaL6j6b3pAZjEq0lN9mZ pOizpb51kB0Wd1O3fXTE3iSK+sk3kvRdlVuSwNueBlKog9Zi6G/jYLtvr1lvArAGj4mL z5+Kj2Olty1dOJJQ1uMTvmBLJ9Q80SptkJvl328K6pTl38n9t5o6AJNlWJzU1a7+xc2a lEDQ== X-Gm-Message-State: AOJu0YwmScY/qoTMcOB/wd7Qldledo/A/RPFUteLcPpBCo/tWbF1BBu0 P1p+WwK8HN0Te/OIKDhDWac= X-Google-Smtp-Source: AGHT+IEg8xPRmGiNWfEyS+qHPHYhvBnEcmfHeFveJut9mgFThXgBbAGTCVoYkJT4lzylzsCNTY+ncw== X-Received: by 2002:adf:fe0d:0:b0:31f:e5cf:6724 with SMTP id n13-20020adffe0d000000b0031fe5cf6724mr3306067wrr.46.1696454932284; Wed, 04 Oct 2023 14:28:52 -0700 (PDT) Received: from nz.home (host86-139-202-110.range86-139.btcentralplus.com. [86.139.202.110]) by smtp.gmail.com with ESMTPSA id k12-20020a5d628c000000b003233a31a467sm96273wru.34.2023.10.04.14.28.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 14:28:51 -0700 (PDT) Received: by nz.home (Postfix, from userid 1000) id CFB46113E8E960; Wed, 4 Oct 2023 22:28:50 +0100 (BST) Date: Wed, 4 Oct 2023 22:28:50 +0100 From: Sergei Trofimovich To: linux-kernel@vger.kernel.org Cc: Eric Biederman , Kees Cook , linux-mm@kvack.org, Andrew Morton Subject: Re: [PATCH] uapi: increase MAX_ARG_STRLEN from 128K to 6M Message-ID: References: <20230924193005.1721655-1-slyich@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230924193005.1721655-1-slyich@gmail.com> X-Rspam-User: X-Stat-Signature: 779bkox9mupz7heybwofxcqk4p795ehe X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 33DAC40013 X-HE-Tag: 1696454933-72931 X-HE-Meta: U2FsdGVkX1/haDrI0i4jKg/nlhw452JjGYyAxYtVbkaMAG5uP0dSM91pNO6xIXe+jY03i+NJjRDgZp+I/fS/iUjwan/p481DScwDicwx/20mCC3pphWAucqOPtYyV5no1cna8JIZ9VgtiMAqKU4Z1jXZtzFKzZu1VtHBsQym4OQIbDgL5xo3nlOKQTkHtbVlyN/e5UiiIiMlBpkbYLAbydQdxZ74Wz2BFJduinCAQqX5AYY0Miwt7yP/fzfTAY6TpK4KjJJmXk3DbXTWIg9oOjcYAnzIFjCTr+JjPQKzmXLzkFi0puAclU8Dz8mjwDqHjwsHQ3NTpw6GqlH3Mb8EuZ1nGzI+5b2zX0sgTvA7sHJr5AdyRWjrXDrsp5pn9RJQIX3Ci7ocIel0Lp1p+JSB2qVCZfFeNpmWC6BLHMAKRQVznWoszoiqkSqEuk8rdCqOgQ7hGXAVcNoNl89aqQwUvl08rgVArcbTUw+eJFD4NlAiOfFa2GvzU3lxVZgBP3AyeJRw45YKsYdg0lRbrDosR4EL+bn0TLrOFyXqjQ04sYJYV0PTBCXbEfd6TXzvC17159OHxMAFtcQ7RJQ0Dl3sns88GwVI/cb7kgorwqffo/yIGlaRYs3B7UdiO9gvzjUp8NPuIGIRNCISd2EFJTSOGFHijwXK+6UccieZj+yW3gc/FQxyZNnCq6ch2PaP/rjH6oYOJVHEYMmCjfojLpoglHMvLM48Ycq1zXWkLT5Ek5t+YbUXJWgwyzGgyd3NYd23JB2zCW9Fkf0+VQWN3luv0fuLHeKaNICIcDpT0FDmFptEJq5rfCexy8cDyXMvBAYRrJntb/8SHkLut6aO7BpD0GL7rsUp+xeY99T4xhNnzpnAkKl/ENesDOOGDJp9tUDhCwGZ784AHrJMetceN8xn4NQJ1lbuBIvIfIUVOP/vO07cSBw2HQ2AzZ4KIDUXTI2ATSaOE5ZtPPp4CXvQx3Z hYOVmqnZ CoqEJp7lLkSEP1sgxFVRLcNibCfJOpMR6iyU0uOsljwIbVKR+UmMtUUn5Q/TgVJeGATOrmHfMHgNFTQRGKCtGypqDnxkP2A5Iog5gNcp6sDf4LPTrVOij82vdOxgXozVS28y3TEJslnaTz+4yfu3C8wN+2LB/vCMdi1QohvMH7MKZa8l7V/MdN8n8XB2PyJwqW1B19qnA/+9LUG90NYgrw2rLaJBRqVSThsQhHp50JeWRWdOLjxGFEP7gL55Cf9jedlEzNgDn/9obsMMTVouuXPRWwKG3aO6tab9FCVt1c4P3ugKL1a7d1QEqZsqCoNSM+oIIUU5xei9D+wZV8JTtdnwF8evVnBhk/CqNgSPHn0iUW59F0TJv7B9yPwSfeLMImv8lWYJvH3WF8x+YIIXYBGBIQHwE+8sEPBdfXfO8ctoMlrwemJ29aDGe811zPcsIM+UnVw/sPlZMK2+z2w+nrXch+tsKVMl41WBbfJz4ywM0veLb7/7k7ai1MHt3B37678r9FjAT0gEPIEr3B75d5HrlOA6f3bcU6CocJg2ElBI9UHcrI2bMcMR5nx3lC/KlJeUrv7xGJn22Gyk3ItUbXyXHx5f41VceWMWkg7KUoEhwBpjeT8RN+jZadDCFQccwI5HSaCBzGLNJWyyevLWv4rjn/t0GqTKBsR+3sAdYqbGeFtUvkspEMvgk+uRE3sxKAMjPieQwehd4AocixrpvweTuj8o6s/XWyvFeVo85C+homtRNVFBZt7PEkSzdgvGihxQT9OJfTxd968a6ocrD9Xn61TXMpnusfSv4xwDnTp4H5Qy4REfeAUrlqRdPiwmxf5S6PzIEMehWvh7cLdNCOFqXGwc6lBEWzutT 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 Sun, Sep 24, 2023 at 08:30:05PM +0100, Sergei Trofimovich wrote: > Before the change linux allowed individual execve() arguments or > environment variable entries to be only as big as 32 pages. > > Histroically before b6a2fea3931 "mm: variable length argument support" > MAX_ARG_STRLEN used to be full allowed size `argv[] + envp[]`. > > When full limit was abandoned individual parameters were still limited > by a safe limit of 128K. > > Nowadays' linux allows `argv[]+envp[]` to be as laerge as 6MB (3/4 > `_STK_LIM`). > > Some build systems like `autoconf` use a single environment variable > to pass `CFLAGS` environment variable around. It's not a bug problem > if the argument list is short. > > But some packaging systems prefer installing each package into > individual directory. As a result that requires quite long string of > parameters like: > > CFLAGS="-I/path/to/pkg1 -I/path/to/pkg2 ..." > > This can easily overflow 128K and does happen for `NixOS` and `nixpkgs` > repositories on a regular basis. > > Similar pattern is exhibited by `gcc` which converts it's input command > line into a single environment variable (https://gcc.gnu.org/PR111527): > > $ big_100k_var=$(printf "%0*d" 100000 0) > > # this works: 200KB of options for `printf` external command > $ $(which printf) "%s %s" $big_100k_var $big_100k_var >/dev/null; echo $? > 0 > > # this fails: 200KB of options for `gcc`, fails in `cc1` > $ touch a.c; gcc -c a.c -DA=$big_100k_var -DB=$big_100k_var > gcc: fatal error: cannot execute 'cc1': execv: Argument list too long > compilation terminated. > > I would say this 128KB limitation is arbitrary. > The change raises the limit of `MAX_ARG_STRLEN` from 32 pakes (128K > n `x86_64`) to the maximum limit of stack allowed by Linux today. > > It has a minor chance of overflowing userspace programs that use > `MAX_ARG_STRLEN` to allocate the strings on stack. It should not be a > big problem as such programs are already are at risk of overflowing > stack. > > Tested as: > $ V=$(printf "%*d" 1000000 0) ls > > Before the change it failed with `ls: Argument list too long`. After the > change `ls` executes as expected. > > WDYT of abandoning the limit and allow user to fill entire environment > with a single command or a single variable? > > CC: Eric Biederman > CC: Kees Cook > CC: linux-mm@kvack.org > CC: linux-kernel@vger.kernel.org > Signed-off-by: Sergei Trofimovich Ping. Also +CC: Andrew Morton in case mm tree is a reasonable place for this change. > --- > include/uapi/linux/binfmts.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/uapi/linux/binfmts.h b/include/uapi/linux/binfmts.h > index c6f9450efc12..4e828515a22e 100644 > --- a/include/uapi/linux/binfmts.h > +++ b/include/uapi/linux/binfmts.h > @@ -8,11 +8,11 @@ struct pt_regs; > > /* > * These are the maximum length and maximum number of strings passed to the > - * execve() system call. MAX_ARG_STRLEN is essentially random but serves to > - * prevent the kernel from being unduly impacted by misaddressed pointers. > + * execve() system call. MAX_ARG_STRLEN is as large as Linux allows new > + * stack to grow. Currently it's `_STK_LIM / 4 * 3 = 6MB` (see fs/exec.c). > * MAX_ARG_STRINGS is chosen to fit in a signed 32-bit integer. > */ > -#define MAX_ARG_STRLEN (PAGE_SIZE * 32) > +#define MAX_ARG_STRLEN (6 * 1024 * 1024) > #define MAX_ARG_STRINGS 0x7FFFFFFF > > /* sizeof(linux_binprm->buf) */ > -- > 2.42.0 > -- Sergei