In <20000305123822.B3138@pcep-jamie.cern.ch> Jamie Lokier (lk@tantalophile.demon.co.uk) wrote:
JL> Khimenko Victor wrote:
>> > Feel free to remove the limit altogether and make it dynamic. Something
>> > involving an extra struct mm which you are filling up ptrace-style might
>> > be appropriate. It must be pageable if it can be arbitrarily large.
>>
>> Is it really needed ? This is HARD problem. Since you need to keep in
>> one address space both arguments passed to execve and new argv
>> array. You can try to scan source arguments and make clever rearrange
>> of strings in memory (this is not simple: think about something like
>> execl("bin/echo",plong_string,plong_string+10,0); for example) or you
>> can just clone current process and move agruments from one process to
>> another... Both ways looks EXTREMALLY hairy to me and not needed in
>> most cases
JL> There's a much simpler method. Just create a new address space (struct
JL> mm) and copy into it the same way as ptrace does.
1. What "ptrace does" ? Where is code you are reffering to ?
2. I can be wrong but AFAIK kernel memory is split this way: low 3GiB is
available for process and high 1GiB is for kernel. WHERE you'll put your
"address space (struct vm)" ? Below 3GiB ? There are old process address
spaces (before point of no return that is; and after point of no return
there are NO execve arguments available anymore) and they can fill all this
space. Above 3GiB ? It's kernel space and it's not designed to be swapable.
I'm not sure if kernel can survive if you'll create swapable "struct vm"
there but you'll get LOTS of interesting problems for sure.
JL> To make it pageable, simply store the address of the new mm somewhere
JL> and arrange for the vmscan code to scan it just like the other mms. (A
JL> linked list of mms might be useful for another reason: so that vmscan
JL> doesn't repeatedly scan the same mm when it is shared between threads).
Yes, you can do this. In theory. On practice it's MUCH more deep surgical
operation over linux's memory manager then you want to do if you want just
expand limit for number of arguments.
>> (of course ability to sucessfully call execve with argv
>> bigger then amount of RAM in system is sexy but how often it's really
>> needed?).
JL> If you remove the argv limit but don't make execve pageable, then you
JL> have a DOS attack. A nasty one: you can lock XXX megabytes instantly.
JL> The pages are locked until the new file is mapped, and you can arrange
JL> for that to take a long time.
NO! They are locked only till type of file is determined and "point of no
return is reached". It still can be long, of course.
JL> It doesn't have to be larger than RAM. Just 10 concurrent 10MB
JL> attempted execves would be a DOS on most systems. You could limit it in
JL> the same way that a limit on lockable user pages has been proposed
JL> generally.
Are you looked on patch at all ? I've NOT removed limit. I just made it
configurable at run-time (only root can do this obviously). And root is not
supposed to be stupid, you know...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:18 EST