| 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
| ||
|
Date: Fri, 22 Jul 2022 09:02:11 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Scott Branden <scott.branden@...adcom.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Arnd Bergmann <arnd@...db.de>,
Russell King <linux@...linux.org.uk>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Beznea <claudiu.beznea@...rochip.com>,
Florian Fainelli <f.fainelli@...il.com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
Alexander Shiyan <shc_work@...l.ru>,
Alim Akhtar <alim.akhtar@...sung.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Vladimir Zapolskiy <vz@...ia.com>,
Taichi Sugaya <sugaya.taichi@...ionext.com>,
Takao Orito <orito.takao@...ionext.com>,
Liviu Dudau <liviu.dudau@....com>,
Sudeep Holla <sudeep.holla@....com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Andrew Lunn <andrew@...n.ch>,
Gregory Clement <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Aaro Koskinen <aaro.koskinen@....fi>,
Janusz Krzysztofik <jmkrzyszt@...il.com>,
Tony Lindgren <tony@...mide.com>,
Neil Armstrong <narmstrong@...libre.com>,
Dinh Nguyen <dinguyen@...nel.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-aspeed <linux-aspeed@...ts.ozlabs.org>,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE"
<linux-rpi-kernel@...ts.infradead.org>,
"moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES"
<linux-samsung-soc@...r.kernel.org>,
linux-omap <linux-omap@...r.kernel.org>, linux-oxnas@...ups.io,
linux-stm32@...md-mailman.stormreply.com,
linux-sunxi@...ts.linux.dev,
"open list:TEGRA ARCHITECTURE SUPPORT" <linux-tegra@...r.kernel.org>,
Linux-sh list <linux-sh@...r.kernel.org>
Subject: Re: [PATCH 1/6] ARM: refresh defconfig files
On Thu, Jul 21, 2022 at 5:36 PM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 21/07/2022 17:33, Scott Branden wrote:
> > Hi Arnd,
> >
> > On 2022-07-21 07:13, Arnd Bergmann wrote:
> >> From: Arnd Bergmann <arnd@...db.de>
> >>
> >> A lot of Kconfig options have changed over the years, and we tend
> >> to not do a blind 'make defconfig' to refresh the files, to ensure
> >> we catch options that should not have gone away.
> >>
> >> I used some a bit of scripting to only rework the bits where an
> >> option moved around in any of the defconfig files, without also
> >> dropping any of the other lines, to make it clearer which options
> >> we no longer have.
> > Resync is fine. But, it would be great if the defconfig files were kept
> > in sync. Almost every kernel version kconfig options change which affect
> > these files. Could we put in place a defconfig refresh per kernel
> > version to keep them all in sync going forward?
> >
>
> Not entirely, because some Kconfig changes are causing symbols to
> disappear. Also defconfig is expected to include user-visible options,
> even if savedefconfig would drop them.
>
> This is why blind savedefconfig is not acceptable.
Right. I mostly scripted the changes to move the options around, but
had to do a few files manually so I can't fully automate this, and
the removed options always need manual inspection. There are still
around 400 lines in the defconfig files that go away after a
savedefconfig, and it's a lot of work to go through those.
I might do a few more of these, but if anyone wants to help, these
are the most common lines that get dropped, sorted by frequency:
34 -# CONFIG_VGA_CONSOLE is not set
32 -CONFIG_NET_ETHERNET=y
26 -CONFIG_NFS_V3=y
22 -# CONFIG_CRYPTO_ANSI_CPRNG is not set
20 -CONFIG_PM=y
18 -CONFIG_FPE_NWFPE=y
18 -# CONFIG_INET_XFRM_MODE_TUNNEL is not set
18 -# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
18 -# CONFIG_INET_XFRM_MODE_BEET is not set
15 -CONFIG_SYSFS_DEPRECATED_V2=y
15 -CONFIG_DEBUG_KERNEL=y
15 -# CONFIG_BLK_DEV_BSG is not set
14 -# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
14 -# CONFIG_INPUT_MOUSEDEV is not set
12 -CONFIG_LEDS=y
12 -CONFIG_AEABI=y
11 -CONFIG_NET_PCMCIA=y
11 -CONFIG_GPIO_SYSFS=y
10 -# CONFIG_ENABLE_MUST_CHECK is not set
9 -CONFIG_LEDS_CPU=y
9 -# CONFIG_EXT3_FS_XATTR is not set
8 -CONFIG_CRYPTO_SHA512=m
8 -CONFIG_BINFMT_AOUT=y
8 -# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
7 -CONFIG_SND_PCM_OSS=m
7 -CONFIG_SND_MIXER_OSS=m
7 -CONFIG_SMB_FS=m
7 -CONFIG_MTD_M25P80=y
6 -CONFIG_NET_PCI=y
6 -CONFIG_CRYPTO_ECB=m
5 -CONFIG_SECCOMP=y
5 -CONFIG_MEDIA_CAMERA_SUPPORT=y
5 -CONFIG_IPV6=y
5 -CONFIG_CRYPTO_TEA=m
5 -CONFIG_CRYPTO_SHA256=m
5 -CONFIG_CRYPTO_KHAZAD=m
5 -CONFIG_CRYPTO_ARC4=m
5 -CONFIG_BACKLIGHT_PWM=y
5 -# CONFIG_NET_CADENCE is not set
The majority of these lines are options that no longer exist and are
not needed, or things that dropped off because they get selected by
something else.
The interesting ones we need to catch are the ones that should be
enabled but are either renamed to something else or gained a
dependency that now also needs to be turned on.
Arnd
Powered by blists - more mailing lists