linux-kernel - Re: Sysfs and suicidal attributes

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] [day] [month] [year] [list]

Date:	Wed, 11 Jul 2007 11:04:24 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Tejun Heo <htejun@...il.com>
cc:	Cornelia Huck <cornelia.huck@...ibm.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Sysfs and suicidal attributes

On Wed, 11 Jul 2007, Tejun Heo wrote:

> Alright, there's our confusion.  I thought you were gonna use dev->sem
> to protect new device addition && driver binding.  We can use the same
> rwsem directly for binding protection too but I guess there's no big
> difference one way or the other.

The rwsem should not be used for binding protection.  If we did trylock
then binding at the wrong time would fail, which would be bad.  If we
did down_read then we would probably block while holding a device
semaphore, which also would be bad.

> Thanks for enlightening me.  Probably what can be done is blocking
> regular file sysfs nodes automatically and make it optional (optionally
> enable or disable) for bin attrs.

Maybe.  At the moment I don't see any reason to treat binary attributes 
different from text.

It would also be good to find out whether there are any long-running 
sysfs callbacks.

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/