diff mbox series

execve: argument list space enlargement

Message ID 20240103130722.1551670-1-alexs@kernel.org
State New
Headers
Series execve: argument list space enlargement |

Commit Message

alexs@kernel.org Jan. 3, 2024, 1:07 p.m. UTC 
  From: Alex Shi <alexsshi@tencent.com>

Wechat using too long gcc parameters, then get a strace complain:
  execve(...) = -1 E2BIG (Argument list too long)
Have to increase the parameter space for this, stack has enough
space for this enlargement.

Signed-off-by: Alex Shi <alexsshi@tencent.com>
Cc: Alex Shi <alexsshi@tencent.com>
To: linux-kernel@vger.kernel.org
To: linux-mm@kvack.org
To: Kees Cook <keescook@chromium.org>
To: Eric Biederman <ebiederm@xmission.com>
---
 include/uapi/linux/binfmts.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

David Laight Jan. 5, 2024, 12:02 p.m. UTC | #1 
From: alexs@kernel.org
> Sent: 03 January 2024 13:07
> 
> From: Alex Shi <alexsshi@tencent.com>
> 
> Wechat using too long gcc parameters, then get a strace complain:
>   execve(...) = -1 E2BIG (Argument list too long)
> Have to increase the parameter space for this, stack has enough
> space for this enlargement.

They should fix their build so that it doesn't explode.
It'll probably speed up the compiles as well since the
very long argv[] almost certainly comes from a lot of -I dir
options and they slow down the compile.

if they are -Dvar[=val] then '-include file' can be used instead.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Kees Cook Jan. 11, 2024, 12:13 a.m. UTC | #2 
On Wed, Jan 03, 2024 at 09:07:22PM +0800, alexs@kernel.org wrote:
> From: Alex Shi <alexsshi@tencent.com>
> 
> Wechat using too long gcc parameters, then get a strace complain:
>   execve(...) = -1 E2BIG (Argument list too long)
> Have to increase the parameter space for this, stack has enough
> space for this enlargement.

This is the second request recently[1] to expand the argument list size,
but I remain somewhat unconvinced this needs fixing on the kernel side.

[1] https://lore.kernel.org/lkml/202310170957.DF7F7FE9FA@keescook/

If we do change it, though, as I mention in the thread above, I'd prefer
to leave the UAPI alone and just detach the kernel internals from that
hard-coded limit.

-Kees

> 
> Signed-off-by: Alex Shi <alexsshi@tencent.com>
> Cc: Alex Shi <alexsshi@tencent.com>
> To: linux-kernel@vger.kernel.org
> To: linux-mm@kvack.org
> To: Kees Cook <keescook@chromium.org>
> To: Eric Biederman <ebiederm@xmission.com>
> ---
>  include/uapi/linux/binfmts.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/binfmts.h b/include/uapi/linux/binfmts.h
> index c6f9450efc12..717f6cafe8dd 100644
> --- a/include/uapi/linux/binfmts.h
> +++ b/include/uapi/linux/binfmts.h
> @@ -12,7 +12,7 @@ struct pt_regs;
>   * prevent the kernel from being unduly impacted by misaddressed pointers.
>   * MAX_ARG_STRINGS is chosen to fit in a signed 32-bit integer.
>   */
> -#define MAX_ARG_STRLEN (PAGE_SIZE * 32)
> +#define MAX_ARG_STRLEN (PAGE_SIZE * 128)
>  #define MAX_ARG_STRINGS 0x7FFFFFFF
>  
>  /* sizeof(linux_binprm->buf) */
> -- 
> 2.43.0
>
diff mbox series

Patch

diff --git a/include/uapi/linux/binfmts.h b/include/uapi/linux/binfmts.h
index c6f9450efc12..717f6cafe8dd 100644
--- a/include/uapi/linux/binfmts.h
+++ b/include/uapi/linux/binfmts.h
@@ -12,7 +12,7 @@  struct pt_regs;
  * prevent the kernel from being unduly impacted by misaddressed pointers.
  * MAX_ARG_STRINGS is chosen to fit in a signed 32-bit integer.
  */
-#define MAX_ARG_STRLEN (PAGE_SIZE * 32)
+#define MAX_ARG_STRLEN (PAGE_SIZE * 128)
 #define MAX_ARG_STRINGS 0x7FFFFFFF
 
 /* sizeof(linux_binprm->buf) */