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: 13397072 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 4134FCE7A8C for ; Sun, 24 Sep 2023 19:30:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 269936B0182; Sun, 24 Sep 2023 15:30:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2198E6B0184; Sun, 24 Sep 2023 15:30:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E1FA6B0186; Sun, 24 Sep 2023 15:30:21 -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 EA7C76B0182 for ; Sun, 24 Sep 2023 15:30:20 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AF6FFB35E4 for ; Sun, 24 Sep 2023 19:30:20 +0000 (UTC) X-FDA: 81272482200.24.6B982CD Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by imf27.hostedemail.com (Postfix) with ESMTP id E6BED40029 for ; Sun, 24 Sep 2023 19:30:18 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GLut7EFJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of slyich@gmail.com designates 209.85.128.46 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=1695583819; 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=rgDFx3OpC7QRJPhJl74znPd+GcKZN1H5/4UCuW8FWRk=; b=X+6WHQY2y2PKj3cuUfnvpV2PvouoAoGuJPRa7DTcJhDwDNrCHvXc3aAazkGtnS0TVqmGAw i35L7YyDQN+VO8ip7ngI31zei42xdud95BnMu0lwfw8J3ddWqYzH422l9USp5uu1ecJiGi ugi1/8tnqmwc6gS0kGF89cxvry1ZoFI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GLut7EFJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of slyich@gmail.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=slyich@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695583819; a=rsa-sha256; cv=none; b=5/4tmY0yXzv463b5e5zSJJ5NkEJODK5jcpuVE9JnT39gtbf//J3R77e03K/x8iifwjzETc tDgNVJz1HfrXeucGmzz9eD/LZfq13pAjW0X7sipTR6v21eDqn411DO2Cj7X+zZWbui8Kwr vX9UwcnDbXjl8EWpZxdrkk6M6P4rmnA= Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-405524e6740so28171235e9.1 for ; Sun, 24 Sep 2023 12:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695583817; x=1696188617; 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=rgDFx3OpC7QRJPhJl74znPd+GcKZN1H5/4UCuW8FWRk=; b=GLut7EFJXpPRVDqA/3zTGrPor6jEZ6QzftAJeRN1oC9URZt6WBm2tdaZXMzBdtk8ON 76VnX69leO5pGLgLh81zuQQIAeynR8XjC2lqEeqsSU/o4lI9ICwdMCEdEBW4IZMp6vUY c3w6J/EIJC8wv3rigrlnNsif9NgIl3ZJ6MfU/fkZ2lpre2GcNPdiWx0pZBrWx8kzi2wr UU3Gn3iLzAORUVsuVWJFhbKlB3nI5Hi7QV7w8S7KTLtalxtcKxWrjXdpeDVJY3dQzg5v Jyo1ZmdXrAvM6I6P4ebBwHQWam+Quvd3zmvUs2VXsFaP2+eClIY1eTGHQp8C2sFh8HcO 79rg== 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=ZZLqHfip8CZG1mmzNayXQueGnelf+2ZnwtDOL4lO6MGpTMGDDsEmb5N4OHQt5rV17B iSTrP7a68mpMPNG2RZzw0XiQZUCrMMhGvkpuaLQB5MFr7pu4NQAKgbUKtO6QBq85I4R+ DFZZ2PgF7zo4gWFoyrczNg3fo6GPnbIGgXcqlR8ii7N7MZlNFTw/OXnyx9nDBVEX5aHh IWJq1JtbXAKF3p8/f7TQt8607iojk0Ib/dZL7LBgzYpZflvrrdqZWZaOWP8B9aMbUaPa fASi7Cr1morAzlQpeMA4BlDM55X8qqUmD7VB8Pzbps1wHFCNl20WXbWkZi1yFwXcII3L D5mw== X-Gm-Message-State: AOJu0Yyox10jd/7us+vJdSRrF28fiJ+gkkWDSe0A/2xs2XOEM0SqB0Rj btqQd3v2uNUs3ZPb4N+KuQ0= X-Google-Smtp-Source: AGHT+IENeyDzLBf/mxX+t3aCyhbLfEtHBeZYY7KUbadC62npJv3Xi9K3RDZOHY94J2jksRDajCe6+g== 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-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E6BED40029 X-Stat-Signature: 5xkqk7di1byrpfns8ookbzdz8bc5w186 X-Rspam-User: X-HE-Tag: 1695583818-314560 X-HE-Meta: U2FsdGVkX1+WqpsuBmuFs+/R/85hBgpKScSdSnnj/N/EU4vYE+qHM0QTpHDAuYjx5VcPsVZVxwHpFVDg7pGWXnC2bGsUlrk3JDMnGg/zOzj0RYLEbk6yis3m4pHf+b7XFI/De5APPwQyM8EAFgTrIE73VUGkHw6xZvvDVKkikXRmuBrD2hwgOfUIIlu/thnSfxkYUyLZ7+GnirZyDSmymvFMLxibA6kBQvxKPamUL+S9MaMXKJFtuyqXbCZxkh21SFtz6HdZ40oTRzbd2zfAqeSFZEGn+leCtq/A4EEbcWR1jSTiOGkqLYkEOwg3Zys5K6HWE5l0ng04aFWTYAWlmKt8Wh4VC8vwgdLV0nehG7Nb0xc500t6Y5Kdwy8MhfUISr1FnueAiTzmE93Ie8uYmrYIiHREJbN3/toc0N1CToyAPXwkT2ZEKhBen1HNV1hJ95veZqHhyZJ2apvifYZ0/45jzQXgE53xXt9esDHRBuIvlbaq8+rPcW7RcKamdSxC7Zl9RBHdD287FgztaC0e9hBN7hlDGMI1cDQsDERTZBbj2x9n5rBDdegr5YTRyHWEcUJ7XSosD6V+Mqrqds6Y2QIIU8Lh1bpt23Cdm/uy7NnUCS84WrBQPEgAWeQzzFFCrfQ0quE82BeAIICj8SdJ7Gl8VwX5TzcBQ04Uh9Vo9RHQHZN0BUQnoFVMHCORR7C+y9DeDCtIQydGIPybvtvh2bk8+NuH8drq5KZjMbl8JuremwfkP/Z7tal8uBP8wRGZM+ampSTPl9jK6+4HoLNvX4A2fy118DyPoywKr4R50gE/qG82rG048SbfPaypvxaaZvyPpWADGMLXXyQxVqtIJ5OI+YcAA1JdvD+tdqvFj/2n1k3XYXYH9tyavWVnz4Vf32hfBNCDf9SLKdKl7DG1dJ3R835TSDBUdreqpsImt1LstNdqIKztHHMf0EcH9KdjYTKT1oDocnH68ut3V6z t2DTKZco vS2FapErFyX5HmvH/xLn3WEzCyzihF/BBx+oDDjM6nl2/LA2pA3fM7BWP5x3E6hsiyoTOjRTTCu3w2rmhuHP8YJKqho+q6IImb+1KTKyHO0l9x8OnutdF0wJj2/iuI2ifNX29lUfy5Y45Wr7CK9z6+7JHuZh1LGnmSkZYNtv8hm/YYfOjUSaj2XUlKtF+DtTAw/Tgdb30KX7aftfqrrZ5aK0Kd+Yl4SNLjCaJ1T4n1dI6PmumbJ8LsVNzwti7DQtDHMl34nthsrJmGmQr7iDeraHYofz4OBm/+Kx9fDspSKkXhO3+/r13Rhfq10TaL8dWHcbgK65jvuDSnyg6okWawjlkf8om/csz8mqte8NZYdv1VZXcuI7CMWw8Y5lbQPYnOQUGMGHgLC3mlwXU3I/KSswb21B48/j3cTLVbvky+etM2K6NA9Jvsdl9iPTGuBRut+2A1JeXiaYLxfyiCNSZkPZDO5TQ2liFxjjBdSbgugNDreOLtVY1YGOyBcALrm9bHvUEG/ygADqjOjyl6qWhcBVA2TmblsIKrGLZgpD1v1bbDhZEGfmT/bmqyYzCYfWnDbhaj4dZNeQLpPRAIxp9g2+6y8BtdIOuDY61QayyfeKlgkygshbQHs05Hj4k3tavvjEDWMVoFHJhGB004DU7VaWsshSLYFS3euPTbNrkJ+gGuSy8oXvOjMrXdgWrO5Ya5HwIvt1F2TQSgjMsraSBDlQIUpaMC6tVyMOvKjO0o2v6ETCjBiG92/vBoEfAKA+B8J4z7/1o2PI3gso= 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: 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) */