linux-kernel - Re: [PATCH] vt: configurable number of console devices

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]

Message-ID: <20190529233146.GA3671@mit.edu>
Date:   Wed, 29 May 2019 19:31:46 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Trevor Bourget <tgb.kernel@...il.com>
Cc:     Jiri Slaby <jslaby@...e.cz>, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, dhowells@...hat.com
Subject: Re: [PATCH] vt: configurable number of console devices

On Wed, May 29, 2019 at 03:09:11PM -0700, Trevor Bourget wrote:
> Sorry, I hadn't registered that was uapi. You are right, as a
> configuration setting it's an odd thing to expose there.
> That define won't really be any use to user space except for type
> range validation, and as such it would actually be unhelpful for it to
> be other than 63.
> 
> I will add if defined(__KERNEL__) to improve that, so that it will be
> constant for uapi.

It's by design that MAX_NR_CONSOLES is defined in a uapi header.
There are userspace programs that rely on this value (they use it to
declare arrays, so the version that we export to userspace MUST be
largest value that any kernel might support).

That being said, I've done an eyeball inspection to see how manytes
might be saved if we were to shirnk MAX_NR_CONSOLES, and... I don't
see that many bytes.  Maybe 24 bytes per console, so that maximum
savings would less than 1.5k?   Am I missing something?

Yes, we should all worry about kernel bloat; but it's not clear to me
this is a great place to start.  :-)

					- Ted