From: Alex Shi <[email protected]>
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 <[email protected]>
Cc: Alex Shi <[email protected]>
To: [email protected]
To: [email protected]
To: Kees Cook <[email protected]>
To: Eric Biederman <[email protected]>
---
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
From: [email protected]
> Sent: 03 January 2024 13:07
>
> From: Alex Shi <[email protected]>
>
> 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)
On Wed, Jan 03, 2024 at 09:07:22PM +0800, [email protected] wrote:
> From: Alex Shi <[email protected]>
>
> 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 <[email protected]>
> Cc: Alex Shi <[email protected]>
> To: [email protected]
> To: [email protected]
> To: Kees Cook <[email protected]>
> To: Eric Biederman <[email protected]>
> ---
> 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
>
--
Kees Cook