linux-kernel - Re: [resend][PATCH] Added PR_SET_PROCTITLE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 Oct 2009 04:03:45 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	kosaki.motohiro@...fujitsu.com, Bryan Donlan <bdonlan@...il.com>,
	linux-kernel@...r.kernel.org, Ulrich Drepper <drepper@...hat.com>,
	linux-api@...r.kernel.org, Timo Sirainen <tss@....fi>
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.


Download attachment "setproctitle-mutex.patch" of type "application/octet-stream" (3760 bytes)

Download attachment "setproctitle-rwmutex.patch" of type "application/octet-stream" (3378 bytes)

Download attachment "setproctitle-seqlock.patch" of type "application/octet-stream" (4138 bytes)

Download attachment "readtitle.c" of type "application/octet-stream" (672 bytes)

Download attachment "setproctitle.c" of type "application/octet-stream" (571 bytes)