linux-kernel - Re: tty: add 'active' sysfs attribute to tty0 and console device

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:	Tue, 16 Nov 2010 15:57:17 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>,
	Lennart Poettering <lennart@...ttering.net>,
	Werner Fink <werner@...e.de>, Jiri Slaby <jslaby@...e.cz>
Subject: Re: tty: add 'active' sysfs attribute to tty0 and console device

On Tue, 16 Nov 2010 16:46:40 +0100
Kay Sievers <kay.sievers@...y.org> wrote:

> commit be0d5f02c9194fe41c1aad11d7282db117bda938
> Author: Kay Sievers <kay.sievers@...y.org>
> Date:   Tue Nov 9 18:53:59 2010 +0100
> 
>     tty: add 'active' sysfs attribute to tty0 and console device

This is all somewhat weird.

>     Userspace can query the actual virtual console, and the configured
>     console devices behind /dev/tt0 and /dev/console.

All the other vt interface code is in the vt driver, the ioctls for it
are in the vt driver and a query about what is the active vt only has
meaning within that context as you need to post a waitevent first to
track changes during the query. So if you need a VT_GETACTIVE interface
put it in the tty ioctls where it can be properly locked and used.

> +What:		/sys/class/tty/tty0/active
> +Date:		Nov 2010
> +Contact:	Kay Sievers <kay.sievers@...y.org>
> +Description:
> +		 Shows the currently active virtual console
> +		 device, like 'tty1'.
> +		 The file supports poll() to detect virtual
> +		 console switches.

NAK this, its a nonsense interface

Seriously what use is an interface that tells you "what the console might
have been", this is why we have a proper event tracking interface instead.

> +static ssize_t show_cons_active(struct device *dev,
> +				struct device_attribute *attr, char *buf)
> +{
> +	struct console *cs[16];
> +	int i = 0;
> +	struct console *c;
> +	ssize_t count = 0;
> +
> +	acquire_console_sem();
> +	for (c = console_drivers; c; c = c->next) {
> +		if (!c->device)
> +			continue;
> +		if (!c->write)
> +			continue;
> +		if ((c->flags & CON_ENABLED) == 0)
> +			continue;
> +		cs[i++] = c;
> +		if (i >= ARRAY_SIZE(cs))
> +			break;
> +	}
> +	while (i--)
> +		count += sprintf(buf + count, "%s%d%c",
> +				 cs[i]->name, cs[i]->index, i ? ' ':'\n');
> +	release_console_sem();
> +
> +	return count;
> +}
> +static DEVICE_ATTR(active, S_IRUGO, show_cons_active, NULL);

This makes more sense.

> -	device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 0), NULL,
> -			      "tty");
> +	device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 0), NULL, "tty");

Please keep unneccessary reformatting patches out of code changes, submit
them separately.

>  static ATOMIC_NOTIFIER_HEAD(vt_notifier_list);
> @@ -688,6 +696,8 @@ void redraw_screen(struct vc_data *vc, int is_switch)
>  			save_screen(old_vc);
>  			set_origin(old_vc);
>  		}
> +		if (tty0dev)
> +			sysfs_notify(&tty0dev->kobj, NULL, "active");

What is the locking on tty0dev at this point ? Wrong place anyway - we
have vt change notifiers that do this properly and can track other
changes like console sizes, add and remove. See the VT_WAITACTIVE stuff
etc.

> +static ssize_t show_tty_active(struct device *dev,
> +				struct device_attribute *attr, char *buf)
> +{
> +	return sprintf(buf, "tty%d\n", fg_console + 1);
> +}
> +static DEVICE_ATTR(active, S_IRUGO, show_tty_active, NULL);

How do you ensure fg_console returned to user space is right when the
console can change during and after the call ?

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