linux-kernel - Re: [PATCH] vt: Add enable module parameter

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: <45526d98-57b6-456e-babc-61b7331318c0@redhat.com>
Date: Mon, 26 Jan 2026 11:48:50 +0100
From: Jocelyn Falempe <jfalempe@...hat.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Jiri Slaby <jirislaby@...nel.org>, Nicolas Pitre <npitre@...libre.com>,
 Calixte Pernot <calixte.pernot@...noble-inp.org>,
 linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH] vt: Add enable module parameter

On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>> on the kernel command line to enable it or not.
>>>
>>> This says what is happening, but not why?
>>>
>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>
>>> Why are we using a 1990's technology for a new feature?  What is this
>>> going to allow to have happen?  Who needs/wants this?  Who will use it?
>>> For what?
>>
>> The goal is to ease the transition to disable CONFIG_VT.
>>
>> So if this is merged, you can boot without VT on any Linux distribution,
>> without rebuilding the kernel.
> 
> But that's a distro-specific thing, the distro should be enabling or
> disabling the option as it needs, it should not be a user-configurable
> boot-time selection option as userspace depends entirely on this either
> being there or not.  Why would you have a kernel with both options but
> userspace without that?

Actually the userspace side works with or without VT, at least with 
Fedora, I've my Gnome session in both cases.

> 
>> This option will also allow a distribution to disable VT by default, but
>> users that really wants this can enable it on the kernel command line,
>> without rebuilding the kernel.
> 
> Why would a user want that?  If a user really wants it enabled, why
> would userspace even still work and why would they want to not rebuild
> the kernel?

Rebuilding kernel is not user-friendly, changing a kernel cmdline 
parameter is much easier.

> 
>> It will also avoid hacky solution in userspace like this:
>> https://overhead.neocities.org/blog/systemd-logind-seat/#very-hacky-solutions
> 
> Surely that can't be the only way, why can't userspace just handle this
> "properly" if it wants to?

There is no way for userspace to disable the tty that are running in the 
kernel. It can at best ignore them, but for me it's not a proper solution.
> 
>>>> Signed-off-by: Jocelyn Falempe <jfalempe@...hat.com>
>>>> ---
>>>>    drivers/tty/Kconfig | 13 +++++++++++++
>>>>    drivers/tty/vt/vt.c |  5 +++++
>>>>    2 files changed, 18 insertions(+)
>>>>
>>>> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
>>>> index 149f3d53b7608..2b94c2710687a 100644
>>>> --- a/drivers/tty/Kconfig
>>>> +++ b/drivers/tty/Kconfig
>>>> @@ -41,6 +41,19 @@ config VT
>>>>    	  If unsure, say Y, or else you won't be able to do much with your new
>>>>    	  shiny Linux system :-)
>>>> +config VT_ENABLE
>>>> +	depends on VT
>>>> +	default y
>>>> +	bool "enable VT terminal" if EXPERT
>>>
>>> So no one will ever really use this config option?
>>>
>>> And you are doing 2 things in this patch, not just one, unlike what the
>>> changelog said :(
>>
>> I can split that in two if you prefer.
> 
> I'm objecting to the patch doing something other than what the changelog
> describes, which as you know is not a good thing.
> 

ok, I can fix that in a v2.

>> Adding a module parameter, and adding a Kconfig option, to choose the
>> default for this module parameter.
> 
> I really don't like adding new module parameters that we are going to
> have to now support for forever.  Why not just rely on the config option
> being there or not as-is?  That's why we allowed it to be turned off at
> all, because userspace was going to be moved to not need it anymore.
> Why would we want to support "both" at the same time in the kernel?
> 

This parameter is there to ease the transition to VT-less system. So by 
maintaining this few lines of code, it will be possible to deprecate the 
whole VT in the future.

If a module parameter is not a good solution, I'm open to any solution 
that can disable vt from the kernel command line (userspace init runs to 
late to disable vt).

> thanks,
> 
> greg k-h
>