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    [from the cache]
©2003-2011 Jasper Spaans