lkml.org 
[lkml]   [2009]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [resend][PATCH] Added PR_SET_PROCTITLE_AREA option for prctl()
    Hi

    > > >>> The solution is to use the seqlock to detect this, and prevent the
    > > >>> secret information from ever making it back to process B's userspace.
    > > >>> Note that it's not enough to just recheck arg_start, as process A may
    > > >>> reassign the proctitle area back to its original position after having
    > > >>> it somewhere else for a while.
    > > >>
    > > >> Well seqlock is _a_ solution. __Another is to use a mutex or an rwsem
    > > >> around the whole operation.
    > > >>
    > > >> With the code as you propose it, what happens if a process sits in a
    > > >> tight loop running setproctitle? __Do other processes running `ps' get
    > > >> stuck in a livelock until the offending process gets scheduled out?
    > > >
    > > > It does seem like a maximum spin count should be put in there - and
    > > > maybe a timeout as well (since with FUSE etc it's possible to engineer
    > > > page faults that take arbitrarily long).
    > > > Also, it occurs to me that:
    > >
    > > makes sense.
    > > I like maximum spin rather than timeout.
    >
    > Start simple. What's wrong with mutex_lock() on the reader and writer
    > sides? rwsems might be OK too.
    >
    > In both cases we should think about whether persistent readers can
    > block the writer excessively though.

    I thought your mention seems reasonable. then I mesured various locking
    performance.

    no-contention read-read contetion read-write contention
    w/o patch 4627 ms 7575 ms N/A
    mutex 5717 ms 33872 ms (!) 14793 ms
    rw-semaphoe 6846 ms 10734 ms 36156 ms (!)
    seqlock 4754 ms 7558 ms 9373 ms

    Umm, seqlock is significantly better than other.

    <testcase>
    readtitle.c read proctitle 1,000,000 times
    setproctitle.c infinite loop of setproctitle()

    no-contention:
    ./readtitle 1

    read-read contention:
    ./readtitle 1 &; ./readtitle 1&; wait

    read-write contention
    ./setproctitle
    [switch other terminal]
    ./readtitle `pidof setproctitle`


    I agree this testcase is too pessimistic. ps doesn't read /proc/{pid}/cmdline
    so frequently. however if we need to concern DoS attack, we need to mesure
    pessimistic scenario.

    Plus, this result indicate setproctitle-seqlock doesn't need timeout nor
    max spin.

    [unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream]
    \
     
     \ /
      Last update: 2009-10-12 21:13    [W:0.027 / U:21.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site