linux-kernel - Re: autofs: make the autofsv5 packet file descriptor use a packetized pipe

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:	Mon, 30 Apr 2012 13:11:46 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Michael Tokarev <mjt@....msk.ru>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ian Kent <raven@...maw.net>, Thomas Meyer <thomas@...3r.de>,
	autofs@...r.kernel.org
Subject: Re: autofs: make the autofsv5 packet file descriptor use a packetized pipe

On Mon, Apr 30, 2012 at 1:03 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> Thinking about it some more: for v6, I wouldn't use a packetized pipe at
> all (due to the unnecessary extra buffer consumption.)  Instead just put
> the message size in the header and read a large chunk, which may end up
> being more than one packet and may end up with a partial packet at the
> end.  *This is okay*, because there is only one reader, and any
> additional data needed will be gotten the next time around the loop.

Yes, doing multiple streaming packets is good, but then you really do
need to design the protocol for streaming, which very much includes
having that size early in the header. And then you'd better make the
packets really have different sizes, so that you cannot possibly get
it wrong in an app that "knows" that there's one size.

However, in the case of autofs, I don't actually see multiple packets
being that common. Sure, they can happen, but it really looks like the
normal case will always be the trivial ping-pong scenario ("read one
packet, react to it, rinse and repeat").

But using a big buffer and trying to read lots at one time is valid even then.

The thing I *really* hate about the current autofs situation is how it
really does everything you can possibly do wrong. Not at all the
"let's just read as much as we can, and look at the return value to
determine number of bytes/packets", but literally "I know a-priori how
big the packet is, and I will read exactly that many bytes". That
coupled with the psueod-fixed-size packets just made it a very very
fragile thing.

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