linux-kernel - How important is it that tty_write

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-next>] [day] [month] [year] [list]

Message-ID: <4D656679.90907@freescale.com>
Date:	Wed, 23 Feb 2011 13:56:41 -0600
From:	Timur Tabi <timur@...escale.com>
To:	Greg Kroah-Hartman <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: How important is it that tty_write_room doesn't lie?

Greg,

As you may remember, I have a combination console/tty driver that talks to a
serial-like FIFO provided by our hypervisor.  Both tty_operations.write() and
console.write() talk to the same FIFO for character output.

I've implemented a tty_operations.write_room() function that queries the
hypervisor for amount of free space in the FIFO.  I've noticed a subtle bug in
this function, and I was hoping for some advice on how to fix it.

I believe I might have a problem when the following events happen in this order:

1) The TTY layer calls write_room() to determine the amount of free space in the
FIFO.

2) The *console* layer calls console.write() to write some data (e.g. the kernel
interrupted the TTY layer and executed a printk)

3) Control returns to the TTY layer, which calls tty_operations.write(),
assuming that the number returned by the previous call to write_room() is still
correct.

Because of the interjected console write, the FIFO no longer has a much room as
write_room() said it does.  When the TTY layer calls tty_operations.write(), my
driver returns a number smaller than the size of the buffer passed to (i.e. not
all characters were written).  The TTY layer, not expecting this, loses data.

Is my assessment of the situation correct?  If so, is there any way around this
problem that doesn't require implementing *two* software FIFOs in the driver:
one for the console interface, and one for the TTY interface?  If every driver
needs a FIFO like this, wouldn't it be simpler for the TTY and console layers to
provide their own FIFOs?  I feel like I'm missing something obvious.

-- 
Timur Tabi
Linux kernel developer at Freescale

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