Re: [resend][PATCH] Added PR_SET_PROCTITLE_AREA option for prctl()

[KOSAKI Motohiro]

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.

Attachment: setproctitle-mutex.patch
Description: Binary data

Attachment: setproctitle-rwmutex.patch
Description: Binary data

Attachment: setproctitle-seqlock.patch
Description: Binary data

Attachment: readtitle.c
Description: Binary data

Attachment: setproctitle.c
Description: Binary data