linux-kernel - Re: Sysfs attributes racing with unregistration

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 04 Jan 2012 19:07:52 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Tejun Heo <tj@...nel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: Sysfs attributes racing with unregistration

Alan Stern <stern@...land.harvard.edu> writes:

> On Wed, 4 Jan 2012, Eric W. Biederman wrote:
>
>> > Someone (I think Eric, right?) was trying to generalize the semantics
>> > to vfs layer so that severance/revocation capability is generally
>> > available.  IIRC, it didn't get through tho.
>> 
>> Unfortunately I didn't have time to complete the effort of those
>> patches.  The approach was not fundamentally rejected but it needed a
>> clear and convincing use case as well as some strong scrutiny.  But
>> fundamentally finding a way to do that was seen as an interesting,
>> if it could be solved without slowing down the existing cases.
>
> Ted Ts'o has been talking about something similar but not the same -- a
> way to revoke an entire filesystem.  For example, see commit
> 7c2e70879fc0949b4220ee61b7c4553f6976a94d (ext4: add ext4-specific
> kludge to avoid an oops after the disk disappears).
>
> The use case for that is obvious and widespread: Somebody yanks out a
> USB drive without unmounting it first.

Agreed.  The best I have at the moment is a library that can wrap
filesystem methods to implement the hotplug bits.

Do you know how hard it is to remove event up to the filesystem that
sits on top of a block device?

Do you know how hard it is to detect at mount time if a block device
might be hot-plugable?  We can always use a mount option here and
make userspace figure it out, but being to have a good default would
be nice.

If it isn't too hard to get the event up from the block device to the
filesystem when the block device is uncermoniously removed I might just
make the time to have hotunplug trigger a filesystem wide revoke on a
filesystem like ext4.

In addition to sysfs we need the same logic in proc, sysctl, and uio.
So it makes sense to move towards a common library that can do all of
the hard bits.

I just notice that sysctl is currently sysctl is broken in design if not
in practice by having poll methods that will break if you unregister
the sysctls.  Fortunately for the time being we don't have any sysctls
where that case comes up.

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