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

Ingo Molnar
2016-01-19T08:20:33Z

( 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@suse.de> wrote:

> From: Borislav Petkov <bp@suse.de>
>
> 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