Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1311993 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]  x86/kconfig: Sanity-check config file during oldconfig) Ingo Molnar <mingo@kernel.org> - 2016-01-19 09:30 +0100
    Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]  x86/kconfig: Sanity-check config file during oldconfig) Markus Trippelsdorf <markus@trippelsdorf.de> - 2016-01-19 09:50 +0100
      Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]  x86/kconfig: Sanity-check config file during oldconfig) Ingo Molnar <mingo@kernel.org> - 2016-01-19 10:00 +0100
        Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]  x86/kconfig: Sanity-check config file during oldconfig) Borislav Petkov <bp@suse.de> - 2016-01-19 10:50 +0100
    Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]  x86/kconfig: Sanity-check config file during oldconfig) Peter Zijlstra <peterz@infradead.org> - 2016-01-19 10:10 +0100
      Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]  x86/kconfig: Sanity-check config file during oldconfig) Ingo Molnar <mingo@kernel.org> - 2016-01-19 10:20 +0100
    Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]  x86/kconfig: Sanity-check config file during oldconfig) Borislav Petkov <bp@suse.de> - 2016-01-19 10:50 +0100
    Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y Michal Marek <mmarek@suse.cz> - 2016-01-19 11:00 +0100
      Re: [RFC] CONFIG_GENERIC_BOOTABLE_CONFIG=y Ingo Molnar <mingo@kernel.org> - 2016-01-19 11:40 +0100
        Re: [RFC] CONFIG_GENERIC_BOOTABLE_CONFIG=y Linus Torvalds <torvalds@linux-foundation.org> - 2016-01-19 18:30 +0100
          Re: [RFC] CONFIG_GENERIC_BOOTABLE_CONFIG=y "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-19 19:00 +0100
    Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y Måns Rullgård <mans@mansr.com> - 2016-01-19 13:30 +0100
      Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y Michal Marek <mmarek@suse.cz> - 2016-01-19 13:50 +0100
        Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y Måns Rullgård <mans@mansr.com> - 2016-01-19 14:00 +0100
    Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]  x86/kconfig: Sanity-check config file during oldconfig) "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-01-21 23:10 +0100

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

( 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

[toc] | [next] | [standalone]

#1312006

On 2016.01.19 at 09:20 +0100, Ingo Molnar wrote:
> 
> ( 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.

This is essential. Because, believe it or not, there are still users out
there that don't use systemd. And to force enable totally superfluous
config options for them would be bad.

So, as long as this "systemd config" could be easily disabled, your
approach looks fine and would definitely be helpful to many mainstream
distro users. 

-- 
Markus

[toc] | [prev] | [next] | [standalone]

#1312014

* Markus Trippelsdorf <markus@trippelsdorf.de> wrote:

> On 2016.01.19 at 09:20 +0100, Ingo Molnar wrote:
> > 
> > ( 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.
> 
> This is essential. Because, believe it or not, there are still users out
> there that don't use systemd. And to force enable totally superfluous
> config options for them would be bad.

Well, I think the argument I raised later on is important:

> >  [...] 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 ...

I.e. the costs of quirks are _massively_ assymetric: having an extra system call 
or compat option quirk enabled is essentially unmeasurable for those who don't 
technically need them, while it can be a big and hard to debug show-stopper for 
others.

'default y' was supposed to cover such cases, but arguably it's too opaque, I 
think we need a separate, more obvious layer - such as the 
CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y option I suggested.

> So, as long as this "systemd config" could be easily disabled, your approach 
> looks fine and would definitely be helpful to many mainstream distro users.

It sure can be easily disabled, that's a given.

The key point is that I'd like "naively configured" kernels to work on just about 
any Linux distro that allow kernel testing - so the superset of all quirks should 
be included - as long as enabling a quirk does not break things (and none of the 
ones I listed do as far as I've tested).

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1312045

On Tue, Jan 19, 2016 at 09:54:12AM +0100, Ingo Molnar wrote:
> The key point is that I'd like "naively configured" kernels to work on
> just about any Linux distro that allow kernel testing

Vehemently yes!

This is magnitudes more important than having a couple of passive
kilobytes dangling in the kernel image.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1312024

On Tue, Jan 19, 2016 at 09:20:22AM +0100, Ingo Molnar wrote:
> +	# 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

> 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!

So why not group those under CONFIG_SYSTEMD_BLOWS? I still dont have a
machine with that turd on.

[toc] | [prev] | [next] | [standalone]

#1312031

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Jan 19, 2016 at 09:20:22AM +0100, Ingo Molnar wrote:
> > +	# 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
> 
> > 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!
> 
> So why not group those under CONFIG_SYSTEMD_BLOWS? I still dont have a
> machine with that turd on.

I'd definitely (try to) list the reasons for each quirk in the Kconfig lines (as I 
did above), but I'd still keep a single generic option not tied to systemd in 
particular, for the following reasons:

 - I am using many systemd systems, so the quirks are naturally mostly systemd
   related. There might be more non-systemd quirks that I never triggered
   personally. They can be added once people trigger them.

 - Also, even that considered, not all of the options I listed are systemd quirks,
   as I still have a single (albeit simple) non-systemd test machine.

 - I'd like to have a single superset option that principally makes the kernel
   'just work' for newbie testers - without them having to be even aware of
   whether their distro version uses systemd or something else.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1312050

On Tue, Jan 19, 2016 at 09:20:22AM +0100, Ingo Molnar wrote:
> 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...

Tell me about it. SCSI SAS recent breakage case-in-point...

> 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.

Yeah, so I have a different idea how to fix it. I'm going to drop both

	depends on BLK_DEV_INITRD
        select FW_LOADER

and make it build with or without them enabled so that people are free
to do whatever they want and not get the feeling that I'm forcing shit
down their throats.

HOWEVER(!), this, IMHO, won't help with the normal users because then
they'd have to read Kconfig:

+         The preferred method to load microcode is described in
+         Documentation/x86/early-microcode.txt. For that you need to enable
+         CONFIG_BLK_DEV_INITRD in order for the loader to be able to scan the
+         initrd for microcode blobs.

+         Alternatively, you can build-in the microcode into the kernel. For
+         that you need the functionality behind CONFIG_FW_LOADER.

and figure out what to do exactly to have microcode applied.

And this is crap, IMO.

It should JustWork.

I dunno, maybe I should do a separate config option which let people
choose between FW_LOADER and BLK_DEV_INITRD if CONFIG_MICROCODE is
enabled. I need to hack it in and see what it becomes.

Anyway, I'm just giving my example here as a POV for the discussion.

> 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'm working on untangling CONFIG_MICROCODE from BLK_DEV_INITRD so you
won't need to touch the Kconfig. See above.

> 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.

Yeah, people complained that they don't want to run with initrds.

> 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.

CONFIG_EXPERT_MORE

?

> 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

...

> 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!

I know *exactly* what you're talking about!

Yeah, so having an option select *sane* settings but leaving the
possibility to change that for expert users makes sense.

...

> 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).

Yap.

...

> Thoughs?

Sounds like a good idea to me.

Thanks.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1312053 — Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y

On 2016-01-19 09:20, Ingo Molnar wrote:
> 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.

Agreed.


> 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

You should add a prompt so that the option can be disabled. Or make it
default !EXPERT, to have a single "I know what I'm doing"-type of option.

Michal

[toc] | [prev] | [next] | [standalone]

#1312092 — Re: [RFC] CONFIG_GENERIC_BOOTABLE_CONFIG=y

* Michal Marek <mmarek@suse.cz> wrote:

> On 2016-01-19 09:20, Ingo Molnar wrote:
> > 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.
> 
> Agreed.
> 
> 
> > 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
> 
> You should add a prompt so that the option can be disabled. Or make it
> default !EXPERT, to have a single "I know what I'm doing"-type of option.

Yeah, it sure should be interactive. This was pasted from my automated testing 
that isn't interested in unbootable kernels.

So it should be something like:

	config GENERIC_BOOTABLE_CONFIG
	bool "Enable kernel options that are needed to boot typical Linux distributions"
	default y
	...

(I removed the 'SANE' naming as disabling this option is obviously not 'insane'.)

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1312397 — Re: [RFC] CONFIG_GENERIC_BOOTABLE_CONFIG=y

On Tue, Jan 19, 2016 at 2:30 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> So it should be something like:
>
>         config GENERIC_BOOTABLE_CONFIG
>         bool "Enable kernel options that are needed to boot typical Linux distributions"
>         default y
>         ...
>
> (I removed the 'SANE' naming as disabling this option is obviously not 'insane'.)

I think we should just make it distro-specific rather than claiming it
is generic (and inevitably failing).

So we could have a config option for SYSTEMD, which selects stuff
systemd wants, and then distros that use systemd can select that etc.

It shouldn't be about just bootability either. Some of the networking
options end up being security-critical (ie your firewall might not
work if you don't have the right options enabled, leaving you wide
open after you boot).

Done right, you should be able to

 (a) select your CPU (and things like "do you want virtualization etc")
 (b) select your distro
 (c) select your drivers

and pretty much be done with it.

            Linus

[toc] | [prev] | [next] | [standalone]

#1312405 — Re: [RFC] CONFIG_GENERIC_BOOTABLE_CONFIG=y

On 2016-01-19 12:22, Linus Torvalds wrote:
> On Tue, Jan 19, 2016 at 2:30 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>>
>> So it should be something like:
>>
>>          config GENERIC_BOOTABLE_CONFIG
>>          bool "Enable kernel options that are needed to boot typical Linux distributions"
>>          default y
>>          ...
>>
>> (I removed the 'SANE' naming as disabling this option is obviously not 'insane'.)
>
> I think we should just make it distro-specific rather than claiming it
> is generic (and inevitably failing).
>
> So we could have a config option for SYSTEMD, which selects stuff
> systemd wants, and then distros that use systemd can select that etc.
>
> It shouldn't be about just bootability either. Some of the networking
> options end up being security-critical (ie your firewall might not
> work if you don't have the right options enabled, leaving you wide
> open after you boot).
It might be worth looking at Gentoo's kernel patches, they've had one 
for a while now (I think roughly a year and a half) that does pretty 
much this, you get options for each of their officially supported init 
systems (OpenRC, and SystemD, although the systemd option is not 
anywhere near as complete as what was proposed here), one for portage 
(which needs some specific namespace stuff for sandboxing builds), and I 
think one for udev.  Theirs however uses depends instead of selects, but 
I think that fits a bit better (If I tell the config to make sure I can 
boot using a particular init system, I expect it to not let me change 
things that would prevent me from booting using that init system).

[toc] | [prev] | [next] | [standalone]

#1312176 — Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y

Ingo Molnar <mingo@kernel.org> writes:

> 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?

The problem with *any* approach involving Kconfig is that it still
leaves users free to load microcode whenever they want, even if they're
not supposed to.  Doing so apparently works correctly (almost) every
time (how does it fail if it does?), and no warnings are issued to
suggest it might be a bad idea.  Force-enabling BLK_DEV_INITRD isn't
going to make anyone change their boot scripts.  Many might not even
notice that it got silently enabled. So what purpose does it serve to
play games with the config when it has no actual impact on the usage of
the driver?

I'd also like to get a coherent answer to why microcode update is
preferably done from an initrd as opposed to shortly after mounting a
regular disk.  My systems seem perfectly happy doing the latter.

-- 
Måns Rullgård

[toc] | [prev] | [next] | [standalone]

#1312183 — Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y

Dne 19.1.2016 v 13:29 Måns Rullgård napsal(a):
> Force-enabling BLK_DEV_INITRD isn't going to make anyone change their
> boot scripts.

If you are on a regular distro, /sbin/installkernel should do the right
thing: Run mkinitrd / dracut and if the tools are recent enough and
there is a microcode update for your CPU, a cpio with the microcode blob
will be prepended to the initrd. So this is more or less covered.


> I'd also like to get a coherent answer to why microcode update is 
> preferably done from an initrd as opposed to shortly after mounting
> a regular disk.  My systems seem perfectly happy doing the latter.

It's not even done *from* the initrd but way earlier. We learned the
hard way when Intel released a microcode update for Haswell which
disabled TSX: Userspace did not expect the feature flags to change and
previously valid instructions to start trapping. This can in principle
happen again and with any vendor.

Michal

[toc] | [prev] | [next] | [standalone]

#1312188 — Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y

Michal Marek <mmarek@suse.cz> writes:

> Dne 19.1.2016 v 13:29 Måns Rullgård napsal(a):
>> Force-enabling BLK_DEV_INITRD isn't going to make anyone change their
>> boot scripts.
>
> If you are on a regular distro, /sbin/installkernel should do the right
> thing: Run mkinitrd / dracut and if the tools are recent enough and
> there is a microcode update for your CPU, a cpio with the microcode blob
> will be prepended to the initrd. So this is more or less covered.

I'd be rather cross if something suddenly started building initrds on my
systems.  To me they're just a useless level of complexity to maintain.
(I'm not denying they can be useful to others.)

>> I'd also like to get a coherent answer to why microcode update is 
>> preferably done from an initrd as opposed to shortly after mounting
>> a regular disk.  My systems seem perfectly happy doing the latter.
>
> It's not even done *from* the initrd but way earlier. We learned the
> hard way when Intel released a microcode update for Haswell which
> disabled TSX: Userspace did not expect the feature flags to change and
> previously valid instructions to start trapping. This can in principle
> happen again and with any vendor.

OK, I can see how that might be a problem.

-- 
Måns Rullgård

[toc] | [prev] | [next] | [standalone]

#1314566

On Tue, Jan 19, 2016 at 09:20:22AM +0100, Ingo Molnar wrote:
> +	select SYSFS_DEPRECATED
...

> 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.

And you've got it wrong ;)

http://cgit.freedesktop.org/systemd/systemd/tree/README#n54

        udev will fail to work with the legacy sysfs layout:
	          CONFIG_SYSFS_DEPRECATED=n
-- 
 Kirill A. Shutemov

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web