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

Message-ID: <20130723075757.GM4165@ZenIV.linux.org.uk>
Date:	Tue, 23 Jul 2013 08:57:58 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	richard -rw- weinberger <richard.weinberger@...il.com>
Cc:	Richard Weinberger <richard@....at>,
	Lennart Poettering <mzxreary@...inter.de>,
	Ramkumar Ramachandra <artagnon@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] um: change defconfig to stop spawning xterm

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.

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