linux-kernel - Re: [PATCH] um: change defconfig to stop spawning xterm

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:	Wed, 24 Jul 2013 18:49:53 +0200
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	richard -rw- weinberger <richard.weinberger@...il.com>,
	Richard Weinberger <richard@....at>,
	Ramkumar Ramachandra <artagnon@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] um: change defconfig to stop spawning xterm

On Tue, 23.07.13 08:57, Al Viro (viro@...IV.linux.org.uk) wrote:

> 
> On Tue, Jul 23, 2013 at 07:47:07AM +0200, richard -rw- weinberger wrote:
> > Adding Al again, someone dropped him from the CC list...
> 
> FWIW, all this crap stems from the old decision to use major 4 for
> uml consoles.  And it was a bad decision, no arguments here.
> It's also a decision we are years too late to revert.
> 
> a) VT102, let alone the extensions to it, is simply wrong for uml;
> if it's understood by anything, it's on the host userland side.
> xterm(1) has a notion of two-dimensional array of characters on screen,
> organized in logical lines, etc.  So does screen(1).  So does
> drivers/tty/vt/* (i.e. the kernel side of virtual console).  uml
> console does *not* have such a notion - it passes a linear stream
> of octets, sight unseen, to whatever's on the other side of connection.
> Doing an equivalent of drivers/tty/vt/* would mean maintaining such
> a 2D array internally *AND* somehow passing updates to that beast
> to whatever's on the other side.  That could be done (after all,
> libcurses manages), but it won't be compatible with existing setups
> and it should be a separate driver, anyway.  Granted, it would've
> made a whole lot more sense in role of /dev/tty<n>, but it's too late
> for that now.

The UML tty devices are in most regards pretty much like serial TTYs
where there's also no meta-information available which terminal
emulation is actually spoken on it, and that's covered pretty much OK
everyhwere...

> b) changing the major of /dev/tty<n> on uml will break existing setups.
> Ain't feasible.  We probably can get away with making that controlled
> by kernel option, and it might make sense to try going that way, but
> I'm not entirely convinced it's worth bothering.  Up to uml maintainer...
> IMO if we go that way, we ought to pass the relevant part of config
> (i.e. is it xterm or pts or plain opened file) in the event udev
> gets, so that the userland would have at least a chance of dealing
> with another real problem - selecting TERM value for getty.

Which major/minor you use is irrelevant to userspace. The userspace API
however assumes that /dev/tty[1..63] refers to the tty devices of the
virtual console. As long as you provide some other TTY under that name
then the virtual console TTYs you simply provide a broken API to
userspace, and hence programs break. systemd does, gpm does, X11 does,
and everything else that interfaces with the VC via VC APIs does too.

Just pick a different name for the TTYs that UML uses, just not
/dev/tty[1..63] and everything is fine. That's what the virtualization
folks did with their hypervisor consoles, and is what we required from
the container folks too.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--
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/