1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
#[1]LWN.net headlines [2]Comments posted to this article
[3]LWN.net Logo LWN
.net News from the source [4]LWN
* [5]Content
+ [6]Weekly Edition
+ [7]Archives
+ [8]Search
+ [9]Kernel
+ [10]Security
+ [11]Distributions
+ [12]Events calendar
+ [13]Unread comments
+
_________________________________________________________
+ [14]LWN FAQ
+ [15]Write for us
User: ________ Password: ________ Log in
| Subscribe
| Register
[16]Subscribe / [17]Log in / [18]New account
[RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig:
Sanity-check config file during oldconfig)
[Posted January 20, 2016 by corbet]
From: Ingo Molnar <mingo-AT-kernel.org>
To: Borislav Petkov <bp-AT-suse.de>, Linus Torvalds
<torvalds-AT-linux-foundation.org>, Greg Kroah-Hartman
<gregkh-AT-linuxfoundation.org>, Andrew Morton
<akpm-AT-linux-foundation.org>
Subject: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC
PATCH] x86/kconfig: Sanity-check config file during oldconfig)
Date: Tue, 19 Jan 2016 09:20:22 +0100
Message-ID: <20160119082022.GB18237@gmail.com>
Cc: Michal Marek <mmarek-AT-suse.cz>,
=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans-AT-mansr.com>, Markus
Trippelsdorf <markus-AT-trippelsdorf.de>, Thomas Voegtle
<tv-AT-lio96.de>, linux-kernel-AT-vger.kernel.org, x86-ml
<x86-AT-kernel.org>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, Thomas
Gleixner <tglx-AT-linutronix.de>, Andrew Morton
<akpm-AT-linux-foundation.org>, Linus Torvalds
<torvalds-AT-linux-foundation.org>, Jiri Olsa <jolsa-AT-redhat.com>,
Arnaldo Carvalho de Melo <acme-AT-infradead.org>,
=?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker <fweisbec-AT-gmail.com>
Archive-link: [19]Article, [20]Thread
( 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 o
f
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 directio
n,
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_INIT
RD
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 combinatio
n
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 option
s,
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/cgr
oup: 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 me
ssage: "[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 li
st
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 shou
ld
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
__________________________________________
([21]Log in to post comments)
Copyright © 2016, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
References
1. https://lwn.net/headlines/newrss
2. https://lwn.net/headlines/672587/
3. https://lwn.net/
4. https://lwn.net/
5. https://lwn.net/Articles/672587/#t
6. https://lwn.net/current/
7. https://lwn.net/Archives/
8. https://lwn.net/Search/
9. https://lwn.net/Kernel/
10. https://lwn.net/Security/
11. https://lwn.net/Distributions/
12. https://lwn.net/Calendar/
13. https://lwn.net/Comments/unread
14. https://lwn.net/op/FAQ.lwn
15. https://lwn.net/op/AuthorGuide.lwn
16. https://lwn.net/subscribe/
17. https://lwn.net/Login/
18. https://lwn.net/Login/newaccount
19. http://article.gmane.org/gmane.linux.kernel/2129528
20. http://thread.gmane.org/gmane.linux.kernel/2129528
21. https://lwn.net/Login/?target=/Articles/672587/
|