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 ?
See ptrace_writedata in kernel/ptrace.c.
That copies data from one address space to another.
It's not even arch specific.
> 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.
ptrace_writedata copies from the current user address space directly to
a different one. The two address spaces don't need to be mapped
simultaneously, and they are both swappable.
The kernel address space isn't involved, except to create a temporary
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.
The surgery in this case is minor.
Take a look at swap_out in mm/vmscan.c, where it searches the process
list to pick an mm `best'. `best' is chosen based on mm parameters not
process parameters (except p->swappable, which doesn't count).
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
memory map while building arguments. Then at the point of no return you
dump the old map and replace with the new one.
You can just not have an execve_mm at first, and still implement
argument construction using a second mm. That removes the limit, but
doesn't make the pages swappable during construction.
> 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.
That's what I said :-)
> 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...
I read some of the patch and realised you kept a limit, but I didn't
notice the run time configuration part.
I like the idea of removing the limit altogether because it's not
necessary, and large command lines are occasionally useful.
There's no reason why root should have to choose between trusting users
not to abuse this and disabling it, because there's no reason for this
to be abusable at all.
I shall have a look at implementing my idea.
-- Jamie
-
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