linux-kernel - Re: [RFC PATCH 0/3] sysfs: allow suicide

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]

Message-ID: <Pine.LNX.4.44L0.0903251036450.3462-100000@iolanthe.rowland.org>
Date:	Wed, 25 Mar 2009 10:45:04 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Alex Chiang <achiang@...com>
cc:	htejun@...il.com, <greg@...ah.com>, <cornelia.huck@...ibm.com>,
	<kay.sievers@...y.org>, <rusty@...tcorp.com.au>,
	<ebiederm@...ssion.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] sysfs: allow suicide

On Tue, 24 Mar 2009, Alex Chiang wrote:

> Hi all,
> 
> This is a refreshed version of the patch series Tejun posted quite a while
> ago that allowed sysfs attributes to commit suicide directly:
> 
> 	http://thread.gmane.org/gmane.linux.kernel/582130/

> The most contentious part is patch 1/3, wherein sysfs abuses the
> module notifier call chain, and basically prevents all module unloads
> until suicidal sysfs attributes have completed.
> 
> This is poison of a different flavor from last time. The earlier version
> of this series modified the module API and created an interface that
> allowed anyone to inhibit module unload.
> 
> This time, only sysfs is allowed to be so... special. Which is a slight
> improvement, but the question as to whether sysfs should be allowed to
> do something like this is unresolved.

I tend to agree with Eric that this feels a little like a band-aid, and 
a more general solution would be preferable.  But I don't have one to 
offer, and getting the immediate problems fixed is also important.

Why change the inhibit-module-unload interface?  This new approach
seems a lot more complicated than needed; a simple rwsem should work
okay.  Exposing it to the entire kernel when only sysfs uses it doesn't 
matter -- there must be plenty of EXPORTed symbols with only one user.

Which reminds me...  What happens if two different processes write to
the same suicidal sysfs attribute at the same time?

Alan Stern

--
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/