4 ms·

I was interested to learn that the kernel actually allows you to pass 15 million arguments via execve(), with each one allowed to be enormous. It seems very mu

I was interested to learn that the kernel actually allows you to pass 15 million arguments via execve(), with each one allowed to be enormous. It seems very much like asking for trouble - I can't offhand think of a good reason why this would be required. I'm sure there are plenty of programs that have similar memory leaks with commandline args, as many authors might, not unreasonably, think that abuse would be prevented by the shell ARG_MAX, which is 2621440 bytes on many systems. Perhaps some sort of adjustable lower limit might be appropriate here.

mistaken 12y ago
A lower limit could be troublesome with eg. wildcards: `tar cf stuff.tar *`.
- reidrac 12y ago
  I don't know if it is related, but there used to be a limit in shell parameters expansion in exec, that's why xargs was so handy when "rm *.txt" wasn't possible. That was changed some years ago: https://lkml.org/lkml/2007/8/19/44 https://lkml.org/lkml/2007/8/19/44
  - aw3c2 12y ago
    At least in Bash * still won't work if you have a lot of files with long names: $ for i in {1..99999}; do touch "this is a really long filename so lets see what bash does or does not will it fail or will it work"$i; done $ rm * bash: /usr/bin/rm: Argument list too long
- jfindley 12y ago
  When doing things like this, you'll be hitting your shell's ARG_MAX way before you hit the kernel limit. The 15 million craziness only applies to cases where you're calling executables in ways that don't go through the shell, such as execve().
lambda 12y ago
Fire one, arbitrary restrictions lead to their own problems, with people having to implement workarounds that make their code more complicated and bug prone. For another, notice that one of the features they used in this exploit was similar "adjustable lower limits"; changing ulimit values to defeat most of the value that ASLR provides. In general, I think that using safer languages, like Rust, Go, Java, or even modern C++, is more likely to be the answer than imposing new arbitrary limits. These kinds of buffer overruns, failures to remember to free memory, and so on are all too common in C, and can be avoided if you just use safer languages and constructs that do bounds checking and automatic memory management.

mistaken 12y ago

A lower limit could be troublesome with eg. wildcards: `tar cf stuff.tar *`.

reidrac 12y ago
I don't know if it is related, but there used to be a limit in shell parameters expansion in exec, that's why xargs was so handy when "rm *.txt" wasn't possible. That was changed some years ago: https://lkml.org/lkml/2007/8/19/44 https://lkml.org/lkml/2007/8/19/44
- aw3c2 12y ago
  At least in Bash * still won't work if you have a lot of files with long names: $ for i in {1..99999}; do touch "this is a really long filename so lets see what bash does or does not will it fail or will it work"$i; done $ rm * bash: /usr/bin/rm: Argument list too long
jfindley 12y ago
When doing things like this, you'll be hitting your shell's ARG_MAX way before you hit the kernel limit. The 15 million craziness only applies to cases where you're calling executables in ways that don't go through the shell, such as execve().

lambda 12y ago

Fire one, arbitrary restrictions lead to their own problems, with people having to implement workarounds that make their code more complicated and bug prone. For another, notice that one of the features they used in this exploit was similar "adjustable lower limits"; changing ulimit values to defeat most of the value that ASLR provides. In general, I think that using safer languages, like Rust, Go, Java, or even modern C++, is more likely to be the answer than imposing new arbitrary limits. These kinds of buffer overruns, failures to remember to free memory, and so on are all too common in C, and can be avoided if you just use safer languages and constructs that do bounds checking and automatic memory management.