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.
setproctitle-mutex.patch
Description: Binary data
setproctitle-rwmutex.patch
Description: Binary data
setproctitle-seqlock.patch
Description: Binary data
readtitle.c
Description: Binary data
setproctitle.c
Description: Binary data
