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: <20100126024049.GQ21492@const.famille.thibault.fr>
Date:	Tue, 26 Jan 2010 03:40:49 +0100
From:	Samuel Thibault <samuel.thibault@...-lyon.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	William Hubbs <w.d.hubbs@...il.com>, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org, gregkh@...e.de,
	Chris Brannon <cmbrannon79@...il.com>,
	Kirk Reiser <kirk@...sers.ca>
Subject: Re: request for assistance:  accessing ttys from kernel space

Alan Cox, le Tue 26 Jan 2010 02:13:06 +0000, a écrit :
> > What I would like to discuss is how we can access ttys from kernel
> > space.  If we could do this, it would definitely make things much easier
> > for us in speakup.
> 
> Basically - use a line discipline, that lets you sit on top of a tty and
> interact with the hardware

The problem is that to my knowledge, to setup a line discipline, you
need to already have a daemon opening /dev/ttySomething and set up the
line discipline.  You could as well just move all the speakup code into
the daemon.  The point of speakup is to have feedback even when it is
not possible to run such daemon.

Is there another way to set up a line discipline from the kernel itself
without the need from userland intervention, even before any / is
mounted?

> > We need to be able to access the ttys as early as possible in the boot
> > sequence.  Any help, suggestions, or guidance you could give us would be
> > greatly appreciated.
> 
> We may need to make some special provision for that aspect - we already
> do so for the early serial console support.

Maybe the early serial console support layer could be extended a bit so
speakup can use it first during the boot?  For now it's quite tied to
just printing the printk logs. drivers/accessibility/braille_console.c
does manage do make something else, but it happens that the
serial_core.c's uart_console_write puts additional \rs before \ns, which
can be a problem.

Also, for proper speech flow, speakup would need to be able to read
characters from the device.

> The ldisc is the start point then there may be some bits that need to
> be extended around it.

To me it seems like the only missing bit is how to setup the line
discipline from the kernel itself (i.e. how to "open" the device?) as
soon as it becomes safe to rely on the tty layer.

> A bigger problem is going to be the fact non USB serial is vanishing bit
> by bit.

Actually that's precisely why the speakup community is pressing for
proper tty support, in order to get PCI & USB support :)

> We do have a USB console but it's truely crazy stuff and extending it
> scares me 8)

Ideally that'll needed :/

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ