[RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig)

[Ingo Molnar]

( I've Cc:-ed Linus, Greg and Andrew, to see whether doing something like what I 
  suggest below in the x86 architecture would be acceptable. )

* Borislav Petkov <bp@xxxxxxx> wrote:

> From: Borislav Petkov <bp@xxxxxxx>
> 
> Thomas Voegtle reported that doing oldconfig with a .config which has
> CONFIG_MICROCODE enabled but BLK_DEV_INITRD disabled prevents the
> microcode loading mechanism from being built.
> 
> Add a short script which hooks into the "make oldconfig" handling and
> sanity-checks the config file for that discrepancy. It issues a message
> which should hopefully sensitize the user to that issue and point her
> into the right direction.

So it would be much better to just do such things automatically, and only allow 
'safe' combination of options - without the user having to do anything.

The guiding principle is: kernel configuration is (still...) our worst barrier of 
entry for new users/developers, and kernel configuration still sucks very much 
from a UI point of view.

In fact our kernel configuration UI and workflow is still so bad that it's an 
effort to stay current even with a standalone and working .config, even for 
experienced kernel developers...

Adding a (somewhat hacky) post processing script and forcing users to read 
something 99% of them does not have a clue about is a step in the wrong direction, 
IMHO.

So can we do something more intelligent instead, such as modifying the Kconfigs in 
a way that it's not possible to have CONFIG_MICROCODE enabled while BLK_DEV_INITRD 
is disabled?

I'd be fine with a 'select BLK_DEV_INITRD' for example. If people doing super 
specialized setups disagree because they really need that nonsensical combination 
of config options, they can complain and provide a better solution.

In fact on x86 I'd suggest we go farther than that and add a core set of selects 
that can be disabled only through a sufficiently scary "I really know I'm doing 
something utmost weird" (and default disabled) config option.

>From my own randconfig testing I can give a core list of must-have kernel options, 
without which most distros (Fedora, RHEL, Ubuntu, SuSE) won't boot properly:

+config FORCE_MINIMALLY_SANE_CONFIG
+	bool
+	default y
+
+	# so that capset() works (sudo, etc.):
+	select SECURITY
+	select SECURITY_CAPABILITIES
+	select BINFMT_ELF
+
+	select SYSFS
+	select SYSFS_DEPRECATED
+	select PROC_FS
+	select FUTEX
+
+	# newer systemd silently relies on the presence of the epoll system call:
+	select EPOLL
+	select ANON_INODES
+
+	# newer systemd silently hangs durig early init without these:
+	select PROC_SYSCTL
+	select SYSCTL
+	select POSIX_MQUEUE
+	select POSIX_MQUEUE_SYSCTL
+
+	# systemd needs this syscall:
+	select FHANDLE
+
+	# systemd needs devtmpfs: "systemd[1]: Failed to mount devtmpfs at /dev: No such device"
+	select DEVTMPFS
+
+	# systemd needs tmpfs: "systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file or directory"
+	select SHMEM
+	select TMPFS
+
+	# systemd needs timerfd syscalls: "[    8.198625] systemd[1]: Failed to create timerfd: Function not implemented^"
+	select TIMERFD
+
+	# systemd needs signalfd support: "[   45.536725] systemd[1]: Failed to allocate manager object: Function not implemented"
+	select SIGNALFD
+
+	# systemd hangs during bootup without cgroup support:
+	select CGROUPS
+
+	# systemd fails during bootup without this option, with a nonsensical message: "[DEPEND] Dependency failed for File System Check on /dev/sda1."
+	select FILE_LOCKING
+
+	# systemd fails during bootup without this option:
+	select FSNOTIFY
+	select INOTIFY_USER
+
+	# won't boot otherwise:
+	select RD_GZIP
+	select BLK_DEV_INITRD
+
+	# old F6 userspace needs vsyscalls:
+	select X86_VSYSCALL_EMULATION if X86_64
+	select IA32_EMULATION if X86_64

And yes, many of these options are members of the 'SystemD debuggability Hall Of 
Shame'... It cost me many, many days of painful config-bisection to figure the 
often obscure dependencies out, so we might as well upstream this information.

Many braincells died to bring us this information!

Note that some of these have sub-dependencies (and super-dependencies) so the list 
isn't complete from a Kconfig language POV - but it lists most of the 'must have' 
leaf features and would form a good starting point.

The idea is that if you have this option enabled, the rest of kernel config should 
be 'fool proof' - or at least failures should be a lot more obvious (such as a 
missing hardware driver or a missing filesystem driver).

I'd keep this option x86-only at least initially, because that's still the space 
where most of our newbie testers come from, and because I'd like to see how this 
evolves before trying to generalize it to 44 architectures...

Also, I'd not try to be per distro, I'd use a single superset of such config 
options: from a usability POV it's _much_ better to have a few more options 
enabled in a .config of thousands of entries, than to accidentally have the one 
option not enabled that your user-space somehow critically depends on ...

Thoughs?

Thanks,

	Ingo