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 EC9CDCDB465 for ; Mon, 16 Oct 2023 22:33:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3D038D00C5; Mon, 16 Oct 2023 18:33:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EED3A8D00B8; Mon, 16 Oct 2023 18:33:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8DDA8D00C5; Mon, 16 Oct 2023 18:33:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C67478D00B8 for ; Mon, 16 Oct 2023 18:33:24 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 99CAE1CB38B for ; Mon, 16 Oct 2023 22:33:24 +0000 (UTC) X-FDA: 81352777128.23.676E8F6 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf05.hostedemail.com (Postfix) with ESMTP id 95088100006 for ; Mon, 16 Oct 2023 22:33:21 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=afjzArZ5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of slyich@gmail.com designates 209.85.128.50 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=1697495601; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wEASVEa3xi3QC1ChcRbE9e1Ja+eNEBuwXUOWgyClOv0=; b=ii26ck4rswUIlW0z3uigVKNIpomBJAIiFXLv5MjaXw0iW7HEcy2l2iGAroy3hQ1HbTokKX rNomZ5tgNH9+ZY/5ijMSTPzv59Ses8z9Tw1UnNFnrdwFLyfePNEtr3m/TM1rLiSf4O1Tcj 9uqLqis0yFWgICj1cHUqY8aEyWyiLPk= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=afjzArZ5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of slyich@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=slyich@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697495601; a=rsa-sha256; cv=none; b=3Z4kEGbXCs2qYfzQ5BlVJGr4zNGRhTm6gPQXiM8m+H7YfsHrXFrZgdPYOV3eUis8oecVAQ h5yIpUiHzqQDmks8nI5kKqiovzl9TecC+JxYmRgStZ6ZQGMsdOny9NO8VGk9tPCXm/bDsl dW+OZYx2aGPl5UNqDcMwytI4RzxtAy4= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-405361bb9f7so51007315e9.2 for ; Mon, 16 Oct 2023 15:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697495600; x=1698100400; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=wEASVEa3xi3QC1ChcRbE9e1Ja+eNEBuwXUOWgyClOv0=; b=afjzArZ5c+TXtxsvg8XOKA4dkcwY508BUe0mtHgfeVAGWoXLxLVJXVyvR/NgqydkfA WkKW8syT+UrqAtycjmfbDrujOEp0gsfmFFYJVFOEBnscVPLiCk/Pf7NcVyElxbW32u7e jwr1jquxed2c77lUIDFI7N7xIdbBS2+NWi6uD8VOm3r4baOAO7iG5o2pMparAdwAlRWj 4qkV2lo8z0UPIvq6gYJDj05kRt+f1vgClrDrULuoEZuwN1YhlrJIBbpkXXi3dpcpCSUQ kqTCIgBtRB06IRDJzh596IPDNR8hbklbBkH6kSsp4FQ/M26/ghzECXeGKqp4Cz9Nc7St CxOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697495600; x=1698100400; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wEASVEa3xi3QC1ChcRbE9e1Ja+eNEBuwXUOWgyClOv0=; b=jppmXq0Jr5oT3wS8nB4eZKe3y9qbZS2LdfuuzGRC9+uDh9CKO4dlZAk4RafBbR2bKk UgPjlpT/fgrCeLjtMtbgBejzb7WHm7S3fFTbmdZznWaI3PKvi72oy4iKFG02wxqV3jOm tLnvf9QaSSLAEXclNTtUg2Ow6pUaPf6zI3JvXJ+5I+xWlDHDWk25kw2QqUiyfjqGBum7 HJQnuTBJZko4ZgiQYtgkkyqnpXtDcpx7e49pSg+LMTChO4/dU+O84Qx+4oEVHWn/B0ma OcyRUjZaKNWfHXE3oEVAaq2yZxF5etMtWDgSdiNbnvCEoW7QOZDDt7DYUw7GH51natfv Zx1A== X-Gm-Message-State: AOJu0YymxoPVlqARde8ek0fmW/BNkkwbw6Za8viLehmf76eL/kPCB0LY emGnnec0UnfDEoQrycyQrhU= X-Google-Smtp-Source: AGHT+IFS9hBW8JM6qGbZVtTffTQx6Bw/7qad6dDtVwVkuq4kNxQK0kNtVG3k8rVaec5Bgg0ktvqu2w== X-Received: by 2002:a05:600c:5252:b0:406:8496:bd8b with SMTP id fc18-20020a05600c525200b004068496bd8bmr378559wmb.9.1697495599649; Mon, 16 Oct 2023 15:33:19 -0700 (PDT) Received: from nz ([2a00:23c8:a613:101:729c:d1ff:fe4f:94a3]) by smtp.gmail.com with ESMTPSA id g20-20020a05600c4ed400b003fc0505be19sm238602wmq.37.2023.10.16.15.33.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 15:33:19 -0700 (PDT) Date: Mon, 16 Oct 2023 23:33:18 +0100 From: Sergei Trofimovich To: Kees Cook 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: <20231016233318.2b41ae06@nz> In-Reply-To: <202310161439.BEA904AEE8@keescook> References: <20231016212507.131902-1-slyich@gmail.com> <202310161439.BEA904AEE8@keescook> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 95088100006 X-Stat-Signature: kb8biuw4p9myif3xygiym5mzedjqgrjx X-HE-Tag: 1697495601-514891 X-HE-Meta: U2FsdGVkX1+TDMdNx8B3zhUwdzR90Q8dB+ruRtK0vuARLzRRmQY+ku2fJ73wsQ3Y9BtyWGUY/NQI1rme1hchVMKG1n5aOUoIQKR4y77GJYoif9GfN1RxUuvakx0NLaBRAN4Pj8qeH5Jv0SBk6qOnY/StNjwn/O0M/q4dtVkaYD2NIpsyVFCHzgS+BRmbZ7Lu2Q0eZ3K3GlHlfD+tYZL4tsTqG9xXwJyqVme77sa57cNW9+g6ir623GWJHlVQyF+TcewYuxQ/yUhEf/pfgbjlNKFR6AQKEyOXKp/H/wRCVjdwzFRj2K2+TzFJ6XuScCxUeImp3cxonMRT0d3Sk5YfjHMyLzfyPadMDoIdmS7sajcXtuitt1DDcUkOu8Gk/8VOiQcXz9wB0+f17ebTA3gW+RpgCc/3ybeBnKhqD3wGZu+EISeOmhrWTuCGOOMBnyaBqiLtp5g8DTnZCymqIzAe2Zw57o//tCbiT6lAul95yEp5lO6RU4XR3pV67OY8i6p6wKL5haRf2wBE5l6HeIKXsc3Xt96svAnwT1pGRGcyy5UBurhCnVntBWTxAFE0nqDDjc2Hzt2zRrhyTNuYjzKrS/OEnbQ5GoXxUV61SLviOeVf1E5YXiQAgctlzgO5Ybg3MLd2RRNqXaahB+LhgdoFbijOQIsT1+2sHhK8FtSrziCztmuUaOT5KSNo0ONcAvwktFvw5W/plRN5LBg5rIThjzlmGO4xfNDiFL53wv1QRBIL0c26BpUCb5sQOZm8bgIMs2Rp0nm+Rko8xuBEMsovcLyQbuMeRoB+C7H8z1QlejQrnGLfu8MXyzkVpmi5/4cKeW1BrEGUGy2a7ZeMTf6fi2vu9ZxS5sA2bxAwLkLKIphuqHACJv9pHV7Bmju4EbEc9msK+u+kqXo6GEsQgqM07wreEpm7961tuYEw78TnWBws6MHn9vnT2DR5cq5/X9oAM0tgQRWksqk7pY8zwAF l7KMtyGR G3nkRFiCzSIgzNHmdsf/vgTClFBCOtf9saewY5D5TZIs0f5Uof0vTZ8AtV327wU3deGEH1L1OsZVH16ptHhBc76Rr1Vi1vsf/U+ocrsVGKLKL/scqPU9m2buhU3h91S5nHxrzpq0lLwh05HWJ/i1GYBzW53mSPUHSDgdOq0VvTkDzpb4WZU1wY/tdxlxfK7GA5Pw8Zy70NZxRp72SHhmL5B+HmzT2qDEjn3uUgIm1I64jfYfeauOy1OjaVmZKW8kf1oJH/AEAso8mfB+t3OIP5IxG4vhPMp/U5Cc9BBcljyFLmisKMKQshr7Wr2xiDfzW2etZM/MnrZEMwwfGBMKbmIcX65Tc5J2DlGjVbbozxQDIi3bQmu89LjDNvC54wBP9vrmW8NGBjXce4nHVv6EEikmjnEzYQYxVGHl32ZJQUYPftm57sfHYUsaokWhFwmblzlWqLK7iA7gIZLN4dwH6dwWhTfqIfinFLjM4rqAAP1e+kYOeBBVt1us/6LIg+3ntS2wXEEo+OXDNrvFjAQTTXZVdN412JMSD1Bf+yfkaNZMNMm7N4CVoTobvUL1tEfF3BGIVw+2L41SNdd7UyuQKR70yyD8N3eo5Eshb8wQVb+vA1M5gaJ90Ff4sjbXNTV65FLkPTAH2frvAIxZS2meQcUXfFQRChTVtVE4bL4kfdfHPmYNVL5zLIFFk1IoRSm30qK9vCri1Ik4OAZkOxd7Cof7OofLmmoTe2zR9XpMWN+k2FqIC8fFd+3KDQSJkF/26NMXHnH63r8WcGj6/pu2imQRFE37EKin4klY2wtMuNro7A+1jXXyVxr4KBZmmxZ+yKU2QeFFrUlZqhkM/nDPuO3JOHjmp7uYIkKz10Pbj54HVYxS/EqG8nPERAzkRQj/RudWJ 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, 16 Oct 2023 14:50:05 -0700 Kees Cook wrote: > 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? We usually try to stay under the threshold. When the problem arises due to organic growth of inputs over time we either suffer build failures without any reasonable workarounds or if the change was recent and inflated command line options we revert the change and add hacks into other places (like patching `gcc` directly to apply the transformations). Longer term it would be nice for `gcc` to allow unbounded output via response files, but it will take some time to sort out as current flags rewriting expands all flags and response files into a single huge variable and hits the 128K limit: https://gcc.gnu.org/pipermail/gcc/2023-October/242641.html Medium term dropping kernel's arbitrary small limit (this change) sounds like the simplest solution. > > > > 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. Removing the limit entirely in favour of 'bprm->argmin' sounds good. I'll try to make it so and will send v2. What should be the fate of userspace-exported `MAX_ARG_STRLEN` value in that case? Should it stay `(PAGE_SIZE * 32)`? Should it be removed entirely? (a chance of user space build failures). If we are to remove it entirely what should be the reasonable limit in kernel for other subsystems that still use it? fs/binfmt_elf.c: len = strnlen_user((void __user *)p, MAX_ARG_STRLEN); fs/binfmt_elf_fdpic.c: len = strnlen_user(p, MAX_ARG_STRLEN); fs/binfmt_flat.c: len = strnlen_user(p, MAX_ARG_STRLEN); kernel/auditsc.c: len_full = strnlen_user(p, MAX_ARG_STRLEN) - 1; Keeping it at an "arbitrary" 6MB limit looked safe :) > -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 -- Sergei