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]
Date:	Fri, 7 Feb 2014 10:02:02 +0100
From:	Kay Sievers <kay@...y.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Hannes Reinecke <hare@...e.de>,
	systemd Mailing List <systemd-devel@...ts.freedesktop.org>,
	dh.herrmann@...il.com, LKML <linux-kernel@...r.kernel.org>,
	Lennart Poettering <lennart@...ttering.net>,
	Jiri Slaby <jslaby@...e.cz>, Werner Fink <werner@...e.de>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCHv2] tty: Set correct tty name in 'active' sysfs attribute

On Thu, Feb 6, 2014 at 5:29 PM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Thu, Feb 06, 2014 at 04:44:20PM +0100, Hannes Reinecke wrote:
>> On 02/06/2014 04:29 PM, Greg Kroah-Hartman wrote:
>> > On Thu, Feb 06, 2014 at 03:27:43PM +0100, Hannes Reinecke wrote:
>> >> The 'active' sysfs attribute should refer to the currently
>> >> active tty devices the console is running on, not the currently
>> >> active console.
>> >
>> > That's not what Documentation/ABI/sysfs-tty says:
>> >                  Shows the list of currently configured
>> >                  console devices, like 'tty1 ttyS0'.
>> >                  The last entry in the file is the active
>> >                  device connected to /dev/console.
>> >                  The file supports poll() to detect virtual
>> >                  console switches.
>> >
>> The problem is indeed with 'console devices'. There is no such
>> thing; you only have tty devices where the console is running on.
>>
>> >> The console structure doesn't refer to any device in sysfs,
>> >> only the tty the console is running on has.
>> >
>> > That sentance doesn't make sense.
>> >
>> >> So we need to print out the tty names in 'active', not
>> >> the console names.
>> >
>> > But that doesn't match the documentation.
>> >
>> > What exactly are you trying to "fix" here?  What is the problem that the
>> > current file has that is broken?  And as you are changing what this file
>> > means, what will break if the information in the file changes?
>> >
>> systemd is using the 'active' sysfs attribute to figure out on which
>> _tty_ device to start a getty on.
>> As soon as the console name and the tty name are different
>> you have no means of figuring out which _device_ to open.
>> AFAICS the console 'device' (ie the current entry in 'active')
>> doesn't have _any_ equivalent in sysfs; it just so happens that for
>> most console drivers the tty driver name is identical.
>> But this is not a requirement, and fails for drivers which have a
>> different device for the console and the tty.
>>
>> EG on S/390 the 3270 tty has the devices
>>
>> /dev/3270/tty1
>>
>> but the console driver announces the name 'tty3270'.
>> So as per current rules the 'active' attribute contains
>>
>> tty32700
>>
>> which correct as per documentation, but doesn't have _any_
>> equivalent in sysfs.
>>
>> Martin has the grubby details here.
>>
>> But of course, the documentation should be updated to match the new
>> behavior.
>
> Ok, care to send an updated version, that fixes the Documentation as
> well?  If Kay agrees that this is the correct solution, I'll be glad to
> take it.

Sounds good to me. The intention clearly was to point to the device in use,
which we can find then.

I would not expect problems with this change. For common uses it is the
same name already and nothing visibly should change, and for the ones
where it isn't the same, I expect it is not too useful to find the driver
name.

Thanks,
Kay
--
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