[lkml]   [2000]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [FIX] Re: Argument list too long: out of environment space
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.023 / U:14.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site