linux-kernel - Re: still nfs problems [Was: Linux 2.6.37-rc8]

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, 30 Dec 2010 14:25:15 -0500
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Chuck Lever <chuck.lever@...cle.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Arnd Bergmann <arnd@...db.de>, linux-nfs@...r.kernel.org
Subject: Re: still nfs problems [Was: Linux 2.6.37-rc8]

On Thu, 2010-12-30 at 10:50 -0800, Linus Torvalds wrote: 
> On Thu, Dec 30, 2010 at 10:24 AM, Trond Myklebust
> <Trond.Myklebust@...app.com> wrote:
> >
> > There is nothing we can do to protect ourselves against an infinite loop
> > if the server (or underlying filesystem) is breaking the rules w.r.t.
> > cookie generation. It should be possible to recover from all other
> > situations.
> 
> Umm. Sure there is. Just make sure that you return the uncached entry
> to user space, rather than loop forever.
> 
> Looping forever in kernel space is a bad idea. How about just changing
> the "continue" into a "break" for the "uncached readdir returned
> success".

uncached_readdir is not really a problem. The real problem is
filesystems that generate "infinite directories" by producing looping
combinations of cookies.

IOW: I've seen servers that generate cookies in a sequence of a form
vaguely resembling

1 2 3 4 5 6 7 8 9 10 11 12 3...

(with possibly a thousand or so entries between the first and second
copy of '3')

The kernel won't loop forever with something like that (because
eventually filldir() will declare it is out of buffer space), but
userland has a halting problem: it needs to detect that every
sys_getdents() call it is making is generating another copy of the
sequence associated with '4 5 6 7 8 9 10 11 12 3'...

> No halting problems, no excuses. There is absolutely _no_ excuse for
> an endless loop in kernel mode. Certainly not "the other end is
> incompetent".

We should never get an endless loop in _kernel mode_ with the current
scheme, and I can't see that anyone has demonstrated that yet.

> EVERYBODY is incompetent sometimes. That just means that you must
> never trust the other end too much. You can't say "we require the
> server to be sane in order not to lock up".

Unfortunately we must. Call it an NFS protocol failure, but it really
boils down to the fact that POSIX readdir() generates a data stream with
no well-defined concept of an offset. As a result, each and every
filesystem has their own interesting ways of generating cookies to
represent that 'offset'.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com

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