linux-kernel - Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

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]

Date:   Sun, 11 Oct 2020 17:40:27 +0200
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org,
        x86@...nel.org, Collabora Kernel ML <kernel@...labora.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Diego Elio Pettenò <flameeyes@...meeyes.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Willy Tarreau <w@....eu>
Subject: Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

Hi Borislav,

On 11/10/20 14:20, Borislav Petkov wrote:
> On Sun, Oct 11, 2020 at 01:43:44PM +0200, Enric Balletbo i Serra wrote:
>> We're also probably lacking a definition of what normal users mean, because I
>> don't think normal users build their own kernel.
> 
> You'd be surprised.
> 
>> I think that at least X86_AMD_PLATFORM_DEVICE and MFD_INTEL_LPSS_PCI
>> could be common enough to match within the category of needed to run
>> in normal (or common) user mode(s). I can send a patch with only these
>> two options.
> 
> How do you quantify those things are common enough?
> 

How do you quantify those things are NOT common enough? Do you have a number?

I don't have a number, the only I can tell is that both symbols enable support
for I2C, SPI an HS-UART. The AMD one, is found on AMD Carrizo and later
chipsets, the Intel one, is found on Intel Skylake and later. I.e Lots of
laptops need these to have support for the touchpad.

>> But, yes, the main purpose after this patch is the serial console for CI. I saw
>> that there are already some configs with a specific purpose (tiny.config and
>> xen.config). So, I am wondering if would be acceptable support another specific
>> config for CI (i.e kernelci.config). Will it be acceptable?
> 
> Why does this config have to be upstream?

KernelCI is focused on upstream kernel development. KernelCI builds lots of
different versions of the kernel, including stable kernels, and maintainers
trees. It does tests on real hardware, so having a config supporting as much as
possible the x86 hardware that we have in the KernelCI labs will help us to
increase the test coverage and catch more issues.

configs are tied to the kernel version, as one config symbol can be changed,
removed or renamed between kernel versions. Having in a separate project will
imply a maintenance effort for x86 hardware. Note that, for ARM and ARM64
hardware, we don't have this problem because the "normal" defconfigs seems to go
the other way regarding what could be or not in the config. So I think it would
be useful (having it would save hours of maintenance time in a separate project
to test only the x86 hardware).

> Can't your build process
> supply it? 

Yes, it can. As I said, is a matter of maintenance, if we do this we will have a
different workflow for x86 hardware.

Thanks,
 Enric

> Also, can your config be of any use outside of kernel CI?
> 
> Thx.
>