linux-kernel - Re: [PATCH] Add possibility to set /dev/tty number

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: <20160105160308.GA8748@kroah.com>
Date:	Tue, 5 Jan 2016 08:03:08 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
Cc:	Pierre Paul MINGOT <mingot.pierre@...il.com>, jslaby@...e.cz,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add possibility to set /dev/tty number

On Tue, Jan 05, 2016 at 10:43:45AM -0500, Austin S. Hemmelgarn wrote:
> >I don't understand how reducing the number of vt devices makes anything
> >more or less secure, or better yet, more responsive.  Please provide
> >specific details showing how this happens.
> WRT security, the argument isn't that it makes the system inherently more
> secure, but that it makes it easier to prove the system is secure because
> there are fewer unused device nodes in /dev that you need to explain.

No, the "proof" is the same no matter how many vt device nodes you have.

> In a
> way, it's a different aspect of the argument that reducing the number of
> VT's makes /dev less cluttered.  I don't personally agree with doing
> hardware auditing via /dev, but that's a separate discussion.

It's not a discussion, it's a fallacy.

> As far as the argument about hot-plug overhead, that is an issue (albeit a
> very small one) because that's at least 30+ extra uevents for devices that
> will likely never be used, but it's only an issue during boot unless you're
> doing crazy stuff with allocating and freeing VT's all the time.

How long do those 30+ extra uevents at boot time take?  Can you really
measure that?  Especially given that they aren't even being sent to
userspace because you don't have a running userspace at that point in
time?

> My statement in my reply to this particular message still applies
> though, if you're _that_ timing constrained, you should be using a
> real RTOS (Linux can do RT, but it's not optimal for it, especially
> with any of the regularly used userspace implementations).

RT slows down your machine, so you are not making any sense at all here.

Anyway, why are we even arguing?  There's not a usable patch even
present here to discuss....

greg k-h
--
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/