linux-kernel - Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data

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]

Date:	Tue, 22 Mar 2016 14:00:30 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Peter Hurley <peter@...leysoftware.com>,
	Jiri Slaby <jslaby@...e.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrey Vagin <avagin@...tuozzo.com>,
	Pavel Emelianov <xemul@...tuozzo.com>,
	Vladimir Davydov <vdavydov@...tuozzo.com>,
	Konstantin Khorenko <khorenko@...tuozzo.com>
Subject: Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data

On Thu, Mar 17, 2016 at 10:32:44AM +0300, Cyrill Gorcunov wrote:
> On Wed, Mar 16, 2016 at 09:05:06PM -0700, Peter Hurley wrote:
> > > Here is a new ioctl code which simply copies data from read buffer
> > > into the userspace without any additional processing (just like
> > > terminal is sitting in a raw mode).
> > 
> > Maybe I'm overlooking something obvious, but why not do just that;
> > ie., save the termios, reset termios to raw mode and read the entire
> > ldisc read buffer?
> > 
> > Note that saving and resetting termios to raw mode is only necessary
> > for the slave side, as the master side is always in raw mode.
> 
> Hi Peter! Yes we can do that, but there is one significant problem:
> when we read the buffer (draining it) and then during later stages
> of checkpoint something fails -- we need to bring the dumping program
> back to the former state so it won't notice that someone has been
> dumping it. Which means code flow like
> 
>  - read ldisk buffer
>  - ... some other work for checkpoint sake ...
>  - ... obtained some error ...
>  - write ldisk buffer back to restore original content
> 
> and if here write fails (for any reason), the program being
> dupmed will loose ldisk buffer content. we simply can't allow
> this to happen because otherwise checkpoint will work in
> destructive way.
> 
> Moreover there is an option in criu where we allow to dump
> program and leave it in running state, say someone needs
> a snapshot of a state, thus we always must work in non-
> destructive manner.
> 
> Sure, not modifying the kernel would be a preferred way
> for me too.

Ping? Guys, are there some more arguments against this ioctl?
Or some way which I missed suitable for nondestructive read
from a buffer?

> 
> > 
> > Then, two options for restore are:
> > 1) set termios to raw mode, write to peer, restore the saved termios; or
> > 2) restore the saved termios and write to peer.
> > 
> > option 1 will preserve the contents as read but not preserve the line
> > termination state; ie., it will be possible to read multiple lines
> > with a single canonical read.
> > 
> > option 2 will preserve the line termination state (for the most part)
> > but not necessarily the contents which might be re-interpreted.
> > 
> > These two options are not necessarily exclusive; it may be possible
> > to construct a mixed mode for restore based on the original saved
> > termios that reconstitutes both line termination state and read buffer
> > contents.
> > 
> > One thing not accounted for is the column position.

	Cyrill