From patchwork Sun Sep 24 19:30:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergei Trofimovich X-Patchwork-Id: 144143 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp842426vqu; Sun, 24 Sep 2023 14:16:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF3S7XfadNwgGTcsQYFZdmfD6C1PFUP3uFmXYn0exqt+LYubQjTCz9o1WCIW9zkWU6PHvDw X-Received: by 2002:a05:6358:41a1:b0:13a:a85b:a4dc with SMTP id w33-20020a05635841a100b0013aa85ba4dcmr6447985rwc.29.1695590217801; Sun, 24 Sep 2023 14:16:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695590217; cv=none; d=google.com; s=arc-20160816; b=jxbk1W65KVcpa49wnOr65SJ/uYRkzJ42ACe79VVUXdeaoC9vsmCUQ1qS7YsbkchS3e SgoZk12LV1Vb/w6HxwBOse6krFn0XroioOQLyH1tvC5TC17Hb7a2gJKMdYwrsSDr9p4T aiLv9us4vZQcdG5TQbUCpI/cYlrS4KWBixk0dsz8ScFuB32iiIR/6GqtEtq3TWR7EPuW /E9ftSL8RsjX2XiY+djbQwc8M4GOP+0N7qTH70UnivlYXRPEtGVnLqrid3aSusH0VhEL /HsjVXUUYfnMYTFGBU2v0JIUf8MKvU8F5QA6d87R9XY/Zs8djOwU8H/ja84neB6Dx4S5 Rhrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=rgDFx3OpC7QRJPhJl74znPd+GcKZN1H5/4UCuW8FWRk=; fh=wG3QmWZpM0090bJUKPzYAqF7rN0BvP2T7NdNImMklrM=; b=Zegjwi+UEiPe1r8fNfVj24HZP7t5xXLy6arc1vL6wcPe3fWqe9WIHg6TukUOnJEzrR KJMp4LEsBDFbOaKe/4MPXXVzaCipJ6etWwacVlyFnxbWjqEELjg4+e7xGaB6TqLRJDuN sAue2Id/XoowgbWGsNYYSGyUEAnV2DxkE+W40mFl+DcQxmH1BTQURLeSRv7FwrEHg9v6 AwOGqJMNqCsRk3qURkCdyvZm3O6hdV1T9+QBqSDlWMYGtLRlpJb3ZtRXjibTj3/8EnnF h9Dxn1RvhlGoFsyN9hQfvmY6f6YOQI8YfTaI+uSv5w3flQY7WoeA1nqS1qmUYpAa87Aj gkqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=nkcZFVXe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id y193-20020a638aca000000b00578ca751ddbsi8353084pgd.328.2023.09.24.14.16.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Sep 2023 14:16:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=nkcZFVXe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 835E1806A859; Sun, 24 Sep 2023 12:30:46 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229807AbjIXTa1 (ORCPT + 30 others); Sun, 24 Sep 2023 15:30:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229552AbjIXTa0 (ORCPT ); Sun, 24 Sep 2023 15:30:26 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FB55FB for ; Sun, 24 Sep 2023 12:30:19 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4053c6f0db8so41021755e9.3 for ; Sun, 24 Sep 2023 12:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695583817; x=1696188617; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=rgDFx3OpC7QRJPhJl74znPd+GcKZN1H5/4UCuW8FWRk=; b=nkcZFVXeCZvqnp8pjGPtAbTiCWc4qjxCm22zRzk9Yr9KWh3e7A3vs1gdiwhrySe3AM /vmaB7HWPO5npkaR8BhMdPJ5cXY1DxfjslJhQwrBTCqaTRvKUX57ezRwaeCxEMBxBoH2 d0Osd8Gpz+yfbIdSKfXfkQF36TW7ko3sj0p3XZ0wEIwm91VcrMg6E4kKOTr/7jNaWcvl tcVxdVpKLHMLD32+gchMg5WSAYzcfiI3gAFrkp8q1TsDE9JxS1uONZfmQ1lSYg6vDCyZ ImGu2iX3FC4thSBX3q9hni8pXOqnvC1WsqX0dIPaAEpOkzIAdP4pgvVOzCsPZNm0xMFo rV6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695583817; x=1696188617; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rgDFx3OpC7QRJPhJl74znPd+GcKZN1H5/4UCuW8FWRk=; b=KhwbdSBovL1U+ddvMXmieLb3t4t3Tt22EGMeox1q57NUczMK2RAoLDm3h5YeWT+UW1 rE534XcQs3LqV2JArCIDPlwQ1VVATpv8K02ck06FpN6Z2w+YzzLNdUbpZa12ZbkrydyT IG14chyPX4B/aIsyVUCeRDeNhIae9SeIzyonUzyrLRr5erOvUZYH1t7S4ikei4h04XFJ 1JjBjlwUp1sgGlPeah4r0NSgfZ0Ky8rH80q/BIvKxhpT9Qa+bMPdx8+jZa8qsI3pv0Go 1qS9LfaSGXTMsCzi80VBwzVHNWZq3lu/iIwFO0C4fnwcHHDyME8Y+efB78D5ZgRNwuEc oVww== X-Gm-Message-State: AOJu0Yyn4b3V4v79dNck+xlk7H0IrKBFpHWgojtL9h4Stg8mBJVZwgsN ruVUjQ1SwrmPT7Bgf6rh92I= X-Received: by 2002:a05:600c:280b:b0:3fb:e2af:49f6 with SMTP id m11-20020a05600c280b00b003fbe2af49f6mr3935018wmb.39.1695583817290; Sun, 24 Sep 2023 12:30:17 -0700 (PDT) Received: from nz.home ([2a00:23c8:a613:101:f234:417a:2d3e:68c9]) by smtp.gmail.com with ESMTPSA id h4-20020a056000000400b0031aef72a021sm10028430wrx.86.2023.09.24.12.30.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Sep 2023 12:30:16 -0700 (PDT) Received: by nz.home (Postfix, from userid 1000) id 2F43010F655DF4; Sun, 24 Sep 2023 20:30:16 +0100 (BST) From: Sergei Trofimovich To: linux-kernel@vger.kernel.org Cc: Sergei Trofimovich , Eric Biederman , Kees Cook , linux-mm@kvack.org Subject: [PATCH] uapi: increase MAX_ARG_STRLEN from 128K to 6M Date: Sun, 24 Sep 2023 20:30:05 +0100 Message-ID: <20230924193005.1721655-1-slyich@gmail.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sun, 24 Sep 2023 12:30:46 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777955208255423232 X-GMAIL-MSGID: 1777955208255423232 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 --- 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) */