linux-kernel - Re: [PATCH] arch/s390/configs: Change CONFIG_VIRTIO

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: <6e44cc81-fe19-f75b-972f-5c4707f2410f@redhat.com>
Date:   Wed, 28 Apr 2021 11:30:09 +0200
From:   Thomas Huth <thuth@...hat.com>
To:     Christian Borntraeger <borntraeger@...ibm.com>,
        linux-s390@...r.kernel.org, Heiko Carstens <hca@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org, Vasily Gorbik <gor@...ux.ibm.com>,
        Marc Hartmayer <mhartmay@...ux.ibm.com>,
        Halil Pasic <pasic@...ux.ibm.com>, cohuck@...hat.com
Subject: Re: [PATCH] arch/s390/configs: Change CONFIG_VIRTIO_CONSOLE to "m"

On 28/04/2021 10.31, Christian Borntraeger wrote:
> On 28.04.21 10:24, Thomas Huth wrote:
>> In former times, the virtio-console code had to be compiled into
>> the kernel since the old guest virtio transport had some hard de-
>> pendencies. But since the old virtio transport has been removed in
>> commit 7fb2b2d51244 ("s390/virtio: remove the old KVM virtio transport"),
>> we do not have this limitation anymore.
>> Commit bb533ec8bacd ("s390/config: do not select VIRTIO_CONSOLE via
>> Kconfig") then also lifted the hard setting in the Kconfig system, so
>> we can finally switch the CONFIG_VIRTIO_CONSOLE knob to compile this
>> driver as a module now, making it more flexible for the user to only
>> load it if it is really required.
> 
> Isnt that a distro specific decision? I would be perfectly fine to have
> this change in Fedora, Redhat and co.

Sure, I'll try to get it changed there, too.

> Not so sure about defconfig.
> We often use the defconfig in our CI and development things to have a
> kernel config that boots up fine, even without a ramdisk. I agree that
> virtio console is no longer really the most important console but does
> it really hurt?

Well, it's about a default configuration that should be fine for most users. 
I don't think that anybody really uses virtio-console in a ramdisk already 
... or are you really doing that in your CI? If so, then please disregard my 
patch.

Otherwise, I think compiling this as a module is the better choice, since 
most people won't use this at all during run-time, or maybe just use it for 
thing like communicating with the QEMU guest agent, but this is then 
certainly not required during boot up yet and thus the "m" should be fine, too.

> Is any distro using the defconfig unmodified?

Most likely don't. But it's a template for new configs, so we should use 
good defaults here.

  Thomas