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: <99371939-e9b2-4114-8e27-e605ebf941de@redhat.com>
Date: Mon, 26 Jan 2026 13:26:34 +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:59, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
>> 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.
> 
> Great!  Then why is this even needed?  Who wants such a "let's not make
> up our mind until we boot" type of system?
> 
> Given that traditionally the command line is a "secure" thing, that is
> locked down by distros and orginizations, who would ever be able to be
> changing this type of thing?  Who would want to support userspace that
> handles both at the same time?
> 
> I don't see the issue here, if a distro doesn't want to support VT, then
> disable it in the kernel and all is good.  If they do want to support
> it, than enable it.  Don't do both :)

Maybe the real issue is that VT cannot be built as a module.
That way the userspace would be able to load it only if it needs it.

That's probably more complex than my 3 lines patch, but I can try.
Would you prefer it that way?


> 
> thanks,
> 
> greg k-h
>