linux-kernel - Re: [PATCH 15/15] x86/kconfig/32: Synchronize the x86-32 defconfig to the x86-64 defconfig

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: <aBubMpHlXQZYeevi@gmail.com>
Date: Wed, 7 May 2025 19:41:06 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Ard Biesheuvel <ardb@...nel.org>,
	David Woodhouse <dwmw@...zon.co.uk>,
	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Michal Marek <michal.lkml@...kovi.net>
Subject: Re: [PATCH 15/15] x86/kconfig/32: Synchronize the x86-32 defconfig
 to the x86-64 defconfig


* Arnd Bergmann <arnd@...db.de> wrote:

> On Tue, May 6, 2025, at 19:09, Ingo Molnar wrote:
>
> > Just a mechanic synchronization of kernel options enabled: nobody 
> > really develops kernel features on x86-32 anymore, so make sure the 
> > defconfig is roughly equivalent to the 64-bit one, so that testing 
> > doesn't cover some combination that nobody cares about.
> 
> What is the size increase here?
>
> Some of the options you enable look like they might add a lot of code 
> to the vmlinux binary, and 32-bit are often might more limited than 
> 64-bit ones.

16.5MB -> 20.8MB, so well within usual RAM limits of x86-32 testing.

As a comparison, the last x86-32 Debian version's kernel, based on 
v6.1, has a vmlinux with 12.2MB .text and 4.2MB of modules loaded when 
booted into text mode, so 16.4MB total. This goes up substantially if 
any graphics is loaded.

> IOW, is your goal here to keep something that works on actual 32-bit 
> machines, or do you want something that will in practice run on 
> 64-bit machines and have a comparable feature set?

This will work on the vast majority of actual 32-bit machines in the 
i686 class and above, but the primary users are kernel developers doing 
test-runs on x86-64. For those who have less than 1GB of RAM, there's 
always tiny-base.config.

> > @@ -50,7 +76,11 @@ CONFIG_ACPI_BGRT=y
> >  CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
> >  CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> >  CONFIG_X86_ACPI_CPUFREQ=y
> > -CONFIG_KPROBES=y
> > +CONFIG_KVM=y
> > +CONFIG_KVM_INTEL=y
> > +CONFIG_KVM_AMD=y
> > +CONFIG_KVM_XEN=y
> > +CONFIG_KVM_MAX_NR_VCPUS=4096
> >  CONFIG_JUMP_LABEL=y
> >  CONFIG_COMPAT_32BIT_TIME=y
> >  CONFIG_MODULES=y
> 
> I have a series to completely remove KVM support for 32-bit. There is 
> one powerpc platform that may keep it, but there is really no point 
> in enabling it here when there are practically zero 32-bit machines 
> that can use it.

That's OK, it will go away once it's removed.

This is an intentionally mechanical mirroring of the 64-bit Kconfig 
over to 32-bit, we've done this in the past as well.

Thanks,

	Ingo