linux-kernel - Re: [PATCH 12/12] Use down_read_unfair() for /sys/<pid>/exe and /sys/<pid>/maps files

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:	Thu, 13 May 2010 09:32:32 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Michel Lespinasse <walken@...gle.com>
Cc:	kosaki.motohiro@...fujitsu.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Waychison <mikew@...gle.com>,
	Suleiman Souhlal <suleiman@...gle.com>,
	Ying Han <yinghan@...gle.com>
Subject: Re: [PATCH 12/12] Use down_read_unfair() for /sys/<pid>/exe and  /sys/<pid>/maps files

> > Is it good idea?
> > So I think /proc shouldn't use unfair thing as backdoor.
> > It doesn't only makes performance improvement, but also
> > DoS chance is there.
> 
> I am not entirely surprised that there is some level of opposition to
> this change (which is in part why it went last in the series).
> 
> Besides keeping it internal, would there be ways to make it acceptable
> to the community ? For example, would it be fine if unfair behavior
> was only used if the caller thread runs with root priviledge ?

Umm. seems no good idea.

Why?

In nowadays, root priviledge should be considered to blocked by security module.
but this using way can't combinate with any security module. at least we need 
more proper and security friendly interface.

> In my opinion the optimal behavior would be if the rwsem could be
> allowed to be grabbed unfairly only as long as there are still fair
> readers on it. However, I don't see how to achieve this given that we
> don't want to slow down the regular, fair code paths.

dumb question.
Why do you need to read /proc/<pid>/exec and /proc/<pid>/maps?
To make new /proc files makes help?

IOW, do we really need unfair reader? can't we make more fine grained lock?



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/