linux-kernel - Re: [PATCH] [RFC] Fix deadlock on regular nonseekable 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] [day] [month] [year] [list]

Message-ID: <20150320193504.GD29656@ZenIV.linux.org.uk>
Date:	Fri, 20 Mar 2015 19:35:06 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Marek Marczykowski-Górecki 
	<marmarek@...isiblethingslab.com>
Cc:	Vitaly Chernooky <vitalii.chernookyi@...ballogic.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Vrabel <david.vrabel@...rix.com>,
	Iurii Konovalenko <iurii.konovalenko@...ballogic.com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Andrii Anisov <andrii.anisov@...ballogic.com>,
	Artem Mygaiev <artem.mygaiev@...ballogic.com>
Subject: Re: [PATCH] [RFC] Fix deadlock on regular nonseekable files

On Fri, Mar 20, 2015 at 08:00:52PM +0100, Marek Marczykowski-Górecki wrote:
> > 	What the devil does that have to do with seeks, anyway?  Exact
> > same problem will happen for blocking read() vs. another read() attempts
> > on the same descriptor.  With perfectly accepted lseek() (which will also
> > have to block, as per 2.9.7).
> 
> Yes, the problem here is because this particular file (/proc/xen/xenbus)
> blocks the read() operation waiting for new events. Because of said
> commit, now it also blocks write() operation used to send some request
> (which would result in some response, so unblocking read() call). It
> shouldn't be a normal file in the first place...

Aha.  OK, so you have something that looks a whole lot like a FIFO in
that respect, and this semantics simply isn't compatible with read()
being atomic wrt write().

So just have that flag explicitly knocked out in your ->open(), preferably
with a comment explaining why is that done.  Having lseek() is a red herring
in that respect - the same problem would exist if that file *did* have
something done on lseek().

That's actually what I'm objecting against - "uses nonseekable_open()" is
used a weird proxy for "can't have read(), write(), etc. atomic wrt each
other".  It's not true in either direction - there's a lot of e.g. procfs
files that are just fine with current exclusion and there can very well
be files _not_ using nonseekable_open() that would break the same way
and for the same reasons as /proc/xen/xenbus does.

It's trivial to fix - either by explicit filp->f_mode &= ~FMODE_ATOMIC_POS;
in xenbus_file_open(), or by adding
static inline void no_atomic_pos(struct file *f)
{
	f->f_mode &= ~FMODE_ATOMIC_POS;
}
somewhere in include/linux/fs.h and having it called in the same
xenbus_file_open().  Either way, it ought to come with something
along the lines of
	/*
	 * we can't live with read() vs. write() atomicity, since we use
	 * write() as source of events returned by read() and write()
	 * called after another thread has blocked in read() waiting for
	 * events cannot be required to wait for that read() to finish.
	 */
next to this removal of FMODE_ATOMIC_POS, whichever way we express it...

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