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 5DB01CDB474 for ; Mon, 16 Oct 2023 21:25:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5BFF8D00C4; Mon, 16 Oct 2023 17:25:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE5038D00B8; Mon, 16 Oct 2023 17:25:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 968068D00C4; Mon, 16 Oct 2023 17:25:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 81A6D8D00B8 for ; Mon, 16 Oct 2023 17:25:20 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5B0B3A0BF3 for ; Mon, 16 Oct 2023 21:25:20 +0000 (UTC) X-FDA: 81352605600.23.4735B24 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf02.hostedemail.com (Postfix) with ESMTP id 8C8F180005 for ; Mon, 16 Oct 2023 21:25:17 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZrRZIjio; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of slyich@gmail.com designates 209.85.128.41 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=1697491517; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=VhbRGW1BROKWRFNldIDINnruhAZTrbVrzlHubFel+Hc=; b=kSaQHZBYcek0kiVLS5hUXuI6CJdJkXaj0LJKijCR+bSuUQUMAC40LTIUHlucPxQ+17EECO I/nRD5hh6CO66vqv+4EVdPVUG1aKUhu8RaUcsZAvP5bEqWpY9EhvNQoY80gPXFiNB0n9xx R4jL7+hwnJ4y4WslSKAqvb68tZwJ/Xw= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZrRZIjio; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of slyich@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=slyich@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697491517; a=rsa-sha256; cv=none; b=Dgd6execJVrWz3s44q1ooWHMCk4Dv8Sgo4Qm1pA4kSe7p9yU+MtB8GvN481u1hSNOu6R4P vfbexmGlouZy+VM7q6BLxrBacshqxrYxlNBi6+VAGEsA+Uqy6bky0zc4lKfrbApwIbwSgi o2Wq0lwUjOWS8PPXzxd9nEln3PCHM+E= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-405524e6768so47913525e9.2 for ; Mon, 16 Oct 2023 14:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697491516; x=1698096316; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=VhbRGW1BROKWRFNldIDINnruhAZTrbVrzlHubFel+Hc=; b=ZrRZIjioKoJ51TgEoovWogPLMf2AP2OU9RzTSaD4mcLHmpFiicXENaubZonUUI/po6 Psq8Ci8LI/jVhOwsYtaGNAQoto421wsIh+PKenca5D2YX2IgOAG5Bz60V4g5j9oIPwLZ nn+RoPUuBRxQ36uzx2yZW3Y92sDhffMMpiLmSrOPrb1+9fktSpU9ZI0qQY2InI3UxqB6 lFBAbLhqzPyNsPBkt2EfOAYuk2yUGrHehomxSG3wOGDAN6Vb2NyZeWpM+WwBNZfI8TV1 uEyi9DMaefv2fMLNggccamyLKqi62obwAiAEnyw3JD9AMPimUgFMlZQ511B8cixNj0Vv uX+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697491516; x=1698096316; 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=VhbRGW1BROKWRFNldIDINnruhAZTrbVrzlHubFel+Hc=; b=P+2f4vttLnP3wklAqaUT1YNFEGTzrXjqxFkn/me0mXL+C+zJPER6JotOIz+pZ/7uiO k4D+AAjQUIGUIKpTuWp3Crxd4hwdMHwKE7p6LAaVhxhDOtxzas0UXWxFqc6u+30eJbKX 5j4FeB+ANIuK4H3E2vpsADIwQV+1FXrg74DOWMHSSmW/oroUUnmwznfKVTEUIA9vE97Q h5iNz7Ew3QuqfU7ze1y6FHZ/XFUGQtfGlDlMKIrS6Stev/+J8+z+LN55VRzIVke+lL/r buNUHa3ToqZ/vKODq81YyQ4/NiWtFXyPmeoOCwadRcJwyUGGOB35gOv8Vr6macomoTUx 6tYw== X-Gm-Message-State: AOJu0Yw4rizzwyIumVU8An3sj1Z9JSoFyBgVjjBkW6kxZnMeKH36X6cW BZNQhsHpfnHUNAsEBxFCr+FUBUnvJXYMXA== X-Google-Smtp-Source: AGHT+IFHtYyWfnE5O+k5ho1gaylct1XmzISsWkPydW8kDPEVlPNwTOG0Jqli/dOqv0AmSYtoKkS23A== X-Received: by 2002:a05:600c:a48:b0:3fe:2a98:a24c with SMTP id c8-20020a05600c0a4800b003fe2a98a24cmr242150wmq.26.1697491515524; Mon, 16 Oct 2023 14:25:15 -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 k21-20020a05600c1c9500b0040607da271asm8229381wms.31.2023.10.16.14.25.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 14:25:14 -0700 (PDT) Received: by nz.home (Postfix, from userid 1000) id 3CD2111AC29807; Mon, 16 Oct 2023 22:25:14 +0100 (BST) From: Sergei Trofimovich To: linux-kernel@vger.kernel.org Cc: Sergei Trofimovich , Andrew Morton , Eric Biederman , Kees Cook , linux-mm@kvack.org Subject: [RESEND PATCH] uapi: increase MAX_ARG_STRLEN from 128K to 6M Date: Mon, 16 Oct 2023 22:25:07 +0100 Message-ID: <20231016212507.131902-1-slyich@gmail.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8C8F180005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: e7hidx6nbfwojzuz9engz3aedatye3s7 X-HE-Tag: 1697491517-615538 X-HE-Meta: U2FsdGVkX19/8tg1qKhfJ6MX7zr3Q0Dtkrt21CfEwX44wWMdSAdF+xWg2ijTu0ChR0PBXkSkvTKyYFz2pLUifv5tYCr4uShi54A4nadbm2Dpb863qSq86bnO8yL+OIHlc/HwweG+fPltXodkSOvrlaaE2XE8Tg7ipn+7EuCD7yg6zVBH6NM0dZW/N0CdLIMzdgSXICglOepDbnlDcC+DMCY8JFpK/GRopFKyGOswbJYrEpryYJ1Sl3vxZqpXk7wvZJM6FsKq1IE2cuwQ2uhoudwcaheS4pBWjcVWZXdIYDsXzTDLMVcQEO/VnwnF1w4qpHyCiDfmi9Q3LibsmdHI7Dr9p/DlbDqg8ku7Ou7ouxLe5FbrrHOHTSstIk17o3EUYwcN73DQ1B7CHg9CL6jG+F9/fjAkBzaQ2hXyiTy9TE0dCGhZQxwog3BMJxToc/i1DOwIL1VTA0O7Qft3xp6/sOqm7dcYgIpUK4jdWjNnw5AkBqbe/EQKXrTvMFef9RJDNjVd2l7Jm13PegJ84hdMJ0MHGMl7dp2D1F4Kh5sA5vgOmiQLbnKFHxgbuTxKBFWBfT+2CIvfrmuQJcG+BdAWEq3pQm1ZrZELUdroLMtI8Fq8Qo2RrU7tpyyCh/z+RSJx4naQYJ5n0k4xq8G0kHstzkxprxYtt+T3UVpNyclIkOdtzmRRdnh8P9sbUVZbHZaTCNKJaxqbJJn3EVrEHMcdzCYxACmJjj+J2sNQrZXnA7ob9kr5HSBAq/QAQif2XMUevNLRkIDakdtX/EPzHp5d4Inxbp4VBDFdCFxbZgCkePb2OXH7L76CFASLZNtYkvdnoJhpzwqbGO+Nf5ThtMNpfqrPAtam0nIxNedABQ1PyQJZB93y0iBFDB8UIwbN/BZzV9nIe7KNRH1hOhKvDpCHj7HRZtMv+PZ2a8On95bseY7tlf2SMK8ADELdl09Hg1z5C5oEvTDnVZAaJtLuMMh Vx+/Hh5p c0DIB9SD4UC74ChjTaw9xMBY/8fe37744NOM4hdK3sFUZ+/HkstHIBq0y5619f1H/n9uofdZ5Jl/R/02x4pyY2BoBMzt2JnThEktsihtNxop0/6iuI6xObGABhfwwuBG5uYhl1WZbOczp6b/K0eHrJnfjdbCOkxr/Ohl5suJAW8/wwD+8kCdz0rMJRJChK+xMcVrfoX73xKM/z2z4XbANHLTaWqznXqkViapAsP3f5acKxX3sdREhDvKXDOAhu3Sdtd7G3l7VIuJW9GAWzkwsdTbA/GuyxlePUQDH1PtCfcGdRxrsbpB0L9UZ2K/2luj68inMRAthWJSQMq9hBVZveRczzyiw4aPpHR+OuM4ORWCgEnwXx0Pgety05MYnQTuA0KnU6vEvNfZpB3aahmz2Ar5ZFXfYQ4raRKJAMJOH4kwfmu+6zNQoiKefuA0h4+hBgkDnxB+SDEEZNFgpTRPESQTwt4I3bEBf3cwkxkWMRDcN0UdrkoL8zdk0C4jbjwnquRPGCmXB7gmcEylORMLOYW15rDyDWPQIKWZAiFn41UYMvMSIMfTEoeL9E0JDT8vngWCvud+51LGz4ZZQOpR1wn/xYg78whz0fSm4T/eENsxAmw38HIXriI1pCQkgKohADG8wupjpdnA1Tfoz1Mw54NOkOMV+MojCQpqX5Orq+F++sRdcIC7NW4XmTehOqVKsuWZNxP6J0Umiskn/rSq771GZkNjOA+BZAQB+JL9VJBDpQCX96yCr/kHzqNXFd9vIUpaRSKEVdOGNaytMFxJncyNalxllINP7D9zeI6ReFaM0CPFktEVrqZjiohUcQ947yrd/h525KC+hQytoTb0gkEc5Ug== 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: 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: 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