linux-kernel - Re: Splicing to/from a tty

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]

Message-ID: <CAHk-=whW7t=3B=iCwYkJ3W-FH08wZNCFO7EJ5qQSqD9Z_tBxrQ@mail.gmail.com>
Date:   Mon, 18 Jan 2021 17:38:55 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Oliver Giles <ohw.giles@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Jiri Slaby <jirislaby@...nel.org>
Subject: Re: Splicing to/from a tty

On Mon, Jan 18, 2021 at 2:20 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So it's not a "real" patch, but with improved buffer handling in
> tty_read(), I think this is actually quite close.

Hmm.

I somehow ended up working on this all because it's a Monday, and I
don't see a lot of pull requests early in the week.

And I think I have a solution for the HDLC "we may need to copy a
packet that might be up to 64kB" issue, that isn't really all that
ugly.

We can just iterate over a random "cookie" that the line discipline
can use any way it wants to. In the case of n_hdlc, it can just put
the 'rbuf' thing it has into that cookie, and then it can copy it all
piece-meal until it is all used up. And if it runs out of space in the
middle, it will return -EOVERFLOW, and we're all good.

The only other thing such a line discipline needs is the offset into
the cookie, but the iterator has to maintain that anyway, so that's
simple enough.

So here's a fourth patch for this thing today, this time with what I
think is actually a working model for the buffer handling.

Other line disciplines *could* use the cookie if they want to. I
didn't do any of that, though.

The normal n_tty line discipline, for example, could easily just loop
over the data. It doesn't need an offset or that 'rbuf' pointer, but
it still needs to know whether the call is the first one or not,
because the first time the n_tty line discipline is called it may need
to wait for a minimum number of characters or whatever the termios
settings say - but obviously once it has waited for it once, it
shouldn't wait for it again the next time around (only on the next
actual full read()). IOW, it would be wrong if the termios said "wait
for 5 characters", and then it saw 68 characters, copied the first 64,
in the first iteration, and than saw "oh, now there are only 4
characters left so now I have to wait for a fifth".

So n_tty could use the cookie purely to see whether it's the first
iteration or not, and it could just set the cookie to a random value
(it always starts out as NULL) to just show what state it is in.

I did *NOT* do that, because it's not technically necessary - unlike
the hdlc packet case, n_tty returning a partial result is not wrong
per se even if we might have reasons to improve on it later.

What do people think about this?

Also, does anybody have any test-code for the HDLC case? I did find an
interesting comment when doing a Debian code search:

  /* Bloody hell... readv doesn't work with N_HDLC line discipline... GRR! */

and yes, this model would allow us to handle readv() properly for hdlc
(and no, the old one did not, because it really wanted to see the
whole packet in *one* user buffer).

But I have no idea if hdlc is even relevant any more, and if anybody
really cares.

Anybody?

              Linus

View attachment "0001-tty-convert-tty_ldisc_ops-read-function-to-take-a-ke.patch" of type "text/x-patch" (21264 bytes)