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 28644CDB465 for ; Mon, 16 Oct 2023 21:50:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FE686B0180; Mon, 16 Oct 2023 17:50:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8875A6B0181; Mon, 16 Oct 2023 17:50:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74F8E6B0182; Mon, 16 Oct 2023 17:50:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5F40E6B0180 for ; Mon, 16 Oct 2023 17:50:09 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 36C4F1CB71D for ; Mon, 16 Oct 2023 21:50:09 +0000 (UTC) X-FDA: 81352668138.05.B0E89E6 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 5E11680013 for ; Mon, 16 Oct 2023 21:50:07 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=jrtFZPZM; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf02.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.175 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697493007; 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=JSyp/Bip5iNls5WLJYDt4GXcuxprjReCLiVejQ3FJcM=; b=7YNjn1UUDupLuqz3KDrkWuf1Y6PPKVp96jOL7LiKPslPqsXhiKZfn0jUhrgg+WarGK6ZJ4 wt5iL+6C1iNeyGy6ym4CX6KkbVcCTnpzyZvpiTsUkI0lSlIC/OAQZIdENMyWuPOSIbjCqb FWxgwjE/v0hc75D5wUjLIQufGyO1HIY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=jrtFZPZM; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf02.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.175 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697493007; a=rsa-sha256; cv=none; b=u6GhozaLRh+3hi2DN/3YTTz4rHC9X+ZsTaavrC5YscK2cuwPZ2ebUjRsCU49GrgPrXIRJf p9voMNlJuNr/5RnmWQ4fa9jLwCNnKgBjGQkU2tESty9zyzIOyPaN0A+OnloKa/E4LabzZ+ HkLwkYcCVudfniC1Azer/KOEq0XsIg0= Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-6b7f0170d7bso2610374b3a.2 for ; Mon, 16 Oct 2023 14:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1697493006; x=1698097806; 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=JSyp/Bip5iNls5WLJYDt4GXcuxprjReCLiVejQ3FJcM=; b=jrtFZPZMEwu/ACTtyJGiBi/tF1HvQB/KcsbLtm66nW+chmiHN+9KFknmS38K5AC5e/ ccmU6yaGFijRWAHwhbqZJIhhEb8Kc28Zg4UcIAsKG0ZtB/n/PesrqOFI9yMr8kjsJ8jz B4UmBFkC2bainaeGYJy28Khb/QI1KIUruH18o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697493006; x=1698097806; 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=JSyp/Bip5iNls5WLJYDt4GXcuxprjReCLiVejQ3FJcM=; b=XIxyBAGOnX31X19BFXor0Q+0/chA0QihR2oZJxR+LkjFe899BbLVp5M6UcXEJDgHlb XaetT9ZxG8CHS5Svu48we+KeWVMN/TVLOoRkuLzzDTaLutOX4il0Bxh0Mym8XdPmi1o4 fKLQHzYv+JQoerf1jIyZ19xmWDgO2tZ+XnvMxtwBOQSIFDOEdQ7cqDa+R3SUec77H0fF 27729X7WCsUfsKIiP/esMRAs2fuUEulGE6NW9nJWys3AWwiQzgPH3uTkMd8s22bQ04YY CXcbdmHJt+/ozYsTWme/No/Xgd57MQQdRx8WKdPzIZ00URQ9FfCRgEGy2fQEFjL05zsA mfkQ== X-Gm-Message-State: AOJu0Yza8vm8AtdzkyQcwCScP480Hr2mgocSN0ZUFvjG8HA6e+2+tZa4 4h5MVWcC/RpZ43CHktbjzoJL9A== X-Google-Smtp-Source: AGHT+IGejCV830CbXRzDCi2Z5qW1DlJaLYLYYKh04MVkP5xwcYrBuRosZiSq0L/FyPCidbDEycVFtw== X-Received: by 2002:a05:6a00:22d0:b0:6be:5e64:babb with SMTP id f16-20020a056a0022d000b006be5e64babbmr504934pfj.18.1697493006180; Mon, 16 Oct 2023 14:50:06 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id m16-20020a6562d0000000b005b1bf3a200fsm88589pgv.1.2023.10.16.14.50.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 14:50:05 -0700 (PDT) Date: Mon, 16 Oct 2023 14:50:05 -0700 From: Kees Cook To: Sergei Trofimovich Cc: linux-kernel@vger.kernel.org, Andrew Morton , Eric Biederman , linux-mm@kvack.org Subject: Re: [RESEND PATCH] uapi: increase MAX_ARG_STRLEN from 128K to 6M Message-ID: <202310161439.BEA904AEE8@keescook> References: <20231016212507.131902-1-slyich@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231016212507.131902-1-slyich@gmail.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 5E11680013 X-Stat-Signature: gum8ixkaaoouo7gheu778o87oi18t6az X-HE-Tag: 1697493007-588280 X-HE-Meta: U2FsdGVkX1+qOR4dRePWXIwlNHk5I2sObsam7RfWno/Gi08kgVDRehuVnTnJR6jyAuCDacxYYrjpFS89FUwMY/cbtkjA45dhaOzTbZloSCr9ChC4a1+qtLcCSNoH2H4DEBaWa/cVGJ+beM3lpgrv6P2RKAVMm9f/ATwEGzxymNQMxan9Vr1BJL1Akq2iIX2SVNju+PxUnePDhIYwuck2hecznNzhmRCjtbrAonIJEeleJeQvHOh0qTq2cf1Ub2iPoDrQOLCJti+JmJsys8fFQHk8eldbF6vlbRJ1FAnofw5W+Wqy2Ko/YWuvCgWRC12719SdbAEmZDk93oqZ5n5KKnIkO0DmdOEhgNH5S+wAf26K7UWG4iyszk/DjpFFs5iYDyLSefi/6OmIO8ShEqeduaH42boWqRrbf1rSiVIxb/x8s0eN77hNLjFO7dLgRWxoW4BqBgVOO1NZk9q6nYsNNDPN/BSqSM5MRiUj0VWkgq8gT3ImC+XxeHrSGdjY78+9/lMq5AmnO9ackyRzIj7IFsj/SAmWjtzlAQfa11VRUY31nTC4hlv5isW792EIrJgRQUXzFlt0lpi8v3fhd4GM1LcWMMbbb8/1srPxsi/foe5QELVFt/gSYddWcHaYhiIOF187XZu92Q4wlN6iiBT5jx1QZY7P81x6oakyGFSIplseqePnmSc5rSo0y8G1X2Nk6EN9kt4kHj/mfZ5OO9ILRK6yeD8jccqShVbzMIyvbdSfgvqtRUP0lXOAl7B4HAd26g/oVowj0VS9N2XEi02KmBcbD7Mfi53Suj9BqEgW7oPSKqbnTmSclkgVndKC8XRR0yTgvHKR9Ie612FzRxxH+rZdD1oi3My47BEuGwDac4QP3tMQOXRKGIqAhGzEzwGqk04tNsHSGWZhPw02JpgQWuMpWFtzbAOyIv/f/Z3eDn4+ZEkiV0tgwJFrcsX2qa1PrfcV3Sm4vd6cK4ofLMA EL8M8hxL Rx7bxKo+diYbemwLYRZKEoh1dsO6Ml9J+CMNGt8d0AlhtILogFHsUDXfeWY92oxhqDH2y+pOpKBFU6ZgOkF4hXJAajtOPaV+0iWUWRn0ST/KXMAvQhKgzUJWKEBf/lUpoe7giBHyfo+7rRH2ZgG/52evwtPdRysIvX1bV/5OcoYaUKZOmBZ6Ss7Ppd7k+3dLNxbWNiQ+U48dmSO7+BRlMhGVinE6pMxCxd1eObxVq3bFV/A8nHNT+IKw0v43W3+xZPfErh2OsbCaPm7fFM2xZf5TkxU1kzaNPq8FaXwjSGLbJNErgysb4XdeG5xz6qD7NwIbeEO1W/le/7i5ILT9CQYh3rOwW44dI3A9Jt9I4rh4d3Wo8B1QZyzSX7lDbJ/QkmAyYjbQ9hTcha7bc1k0gi+jU5PPtV0TMeVRSaaQdZF81vbc7I3BSoZrYtKwiNZa35lgKjd0o5U/ndruLNYYIKXcygiG07C4PzRWoo6ouF89IJwpYgkswT8gyUlrjnH3afDlg/rxLIuv9CQqvolBB3g4YB/WuHqgjb017c9giIppKWK1QbPyP8R0KhQZ3YnoLWPKEckRjm5uciuxct8gLBLUMC4rZSbaxe9p0gfzcxZF9351yzopu1QeJVoD7VvDqs8/PC8wclGZuTFyOsM/cirqa8m3HfqG23tL07uM2hcCzEhzxX3yVdaoFnybILJWYrQXtm+DwYQd5LaZI/Xl4Klm0v66ODy/C8lIUuiJQMYn6U5Zpe5yRCHlcgTNQBH9UXdgw6CBvDITQSgROH9OpdUQmVg== 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 Mon, Oct 16, 2023 at 10:25:07PM +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`). See bprm_stack_limits() for the details, but yes, 3/4 _STK_LIM tends to be the max, unless the rlim_stack is set smaller. > 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. That's ... alarming. What are you doing currently to work around this? > > 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? Changing this value shouldn't risk any vma collisions, since exec is still checking the utilization before starting the actual process replacement steps (see bprm->argmin). It does seem pathological to set this to the full 6MB, though, since that would _immediately_ get rejected by execve() with an -E2BIG, but ultimately, there isn't really any specific limit to the length of individual strings as long as the entire space is less than bprm->argmin. Perhaps MAX_ARG_STRLEN should be removed entirely and the kernel can just use bprm->argmin? I haven't really looked at that to see if it's sane, though. It just feels like MAX_ARG_STRLEN isn't a meaningful limit. -Kees > > CC: Andrew Morton > CC: Eric Biederman > CC: Kees Cook > CC: linux-mm@kvack.org > CC: linux-kernel@vger.kernel.org > Signed-off-by: Sergei Trofimovich > --- > 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 > -- Kees Cook