Messages in this thread | | | Date | Tue, 13 Oct 2009 04:03:45 +0900 (JST) | From | KOSAKI Motohiro <> | Subject | Re: [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] | |