lkml.org 
[lkml]   [2000]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [FIX] Re: Argument list too long: out of environment space
In <20000305183512.A3502@pcep-jamie.cern.ch> Jamie Lokier (lk@tantalophile.demon.co.uk) wrote:
JL> Khimenko Victor wrote:
>> 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 ?

JL> See ptrace_writedata in kernel/ptrace.c.
JL> That copies data from one address space to another.
JL> It's not even arch specific.

Ah. You just want to create totally new adress space, store parameters there
and then use that mm in exec_mmap and further... Hmm. Looks doable. I thought
that execve() does not create new address space at all and wanted to avoid this
(it's SLOW) but turned out that in most cases execve() doing it anyway...

>> 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> ptrace_writedata copies from the current user address space directly to
JL> a different one. The two address spaces don't need to be mapped
JL> simultaneously, and they are both swappable.

JL> The kernel address space isn't involved, except to create a temporary
JL> mapping one page at a time (like your code).

>> 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.

JL> The surgery in this case is minor.

Not such minor. You should move new mm creation from exec_mmap to execve and
rework some code not related to exec at all.

JL> Take a look at swap_out in mm/vmscan.c, where it searches the process
JL> list to pick an mm `best'. `best' is chosen based on mm parameters not
JL> process parameters (except p->swappable, which doesn't count).

JL> Tweak that to iterate look at p->execve_mm too if there is one.
p->>execve_mm is normally 0, but during exec you set it to point to a new
JL> memory map while building arguments. Then at the point of no return you
JL> dump the old map and replace with the new one.

JL> You can just not have an execve_mm at first, and still implement
JL> argument construction using a second mm. That removes the limit, but
JL> doesn't make the pages swappable during construction.

Then it's trikier then my version and does not have any benefits :-)

>> 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> That's what I said :-)

Ok. It's not exactly same thing but close.

>> 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...

JL> I read some of the patch and realised you kept a limit, but I didn't
JL> notice the run time configuration part.

Huh ??? Why there are need to be configuration part ??? It's rlimit and
setrlimit will handle it just fine.

JL> I like the idea of removing the limit altogether because it's not
JL> necessary, and large command lines are occasionally useful.

No. You DO NOT want this. Even swap is limited resource. And with 8MiB of
stack you can construct rougly 4TB (tera!) of arguments. Enough to overflow
any sane swap :-)

JL> There's no reason why root should have to choose between trusting users
JL> not to abuse this and disabling it, because there's no reason for this
JL> to be abusable at all.

There is: in case of OOM linux doing nasty things. Even with latest fixes in
this area.

JL> I shall have a look at implementing my idea.

Yeah :-)

P.S. In fact setproctitle(3) bother me more then unlimited set of arguments
but looks like I'm the only one on this list who ever use sendmail and ftpd :-(



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.057 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site