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

Groups > linux.kernel > #1303523 > unrolled thread

Re: x86/microcode update on systems without INITRD

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

  Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-07 13:20 +0100
    Re: x86/microcode update on systems without INITRD Markus Trippelsdorf <markus@trippelsdorf.de> - 2016-01-07 13:50 +0100
      Re: x86/microcode update on systems without INITRD Thomas Voegtle <tv@lio96.de> - 2016-01-08 10:40 +0100
      Re: x86/microcode update on systems without INITRD Markus Trippelsdorf <markus@trippelsdorf.de> - 2016-01-08 13:30 +0100
      Re: x86/microcode update on systems without INITRD Mike Keehan <mike.keehan@blueyonder.co.uk> - 2016-01-08 14:30 +0100
    Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-08 12:00 +0100
      Re: x86/microcode update on systems without INITRD Måns Rullgård <mans@mansr.com> - 2016-01-08 12:20 +0100
        Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-08 12:40 +0100
          Re: x86/microcode update on systems without INITRD Måns Rullgård <mans@mansr.com> - 2016-01-08 12:50 +0100
            Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-08 13:10 +0100
              Re: x86/microcode update on systems without INITRD Måns Rullgård <mans@mansr.com> - 2016-01-08 13:20 +0100
              Re: x86/microcode update on systems without INITRD Markus Trippelsdorf <markus@trippelsdorf.de> - 2016-01-08 13:20 +0100
                Re: x86/microcode update on systems without INITRD Måns Rullgård <mans@mansr.com> - 2016-01-08 13:30 +0100
                Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-08 13:30 +0100
                  Re: x86/microcode update on systems without INITRD Michal Marek <mmarek@suse.cz> - 2016-01-08 13:50 +0100
                    Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-08 14:40 +0100
                      Re: x86/microcode update on systems without INITRD Michal Marek <mmarek@suse.cz> - 2016-01-08 15:50 +0100
                        Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-11 20:50 +0100
                          Re: x86/microcode update on systems without INITRD Måns Rullgård <mans@mansr.com> - 2016-01-11 21:30 +0100
                            Re: x86/microcode update on systems without INITRD Måns Rullgård <mans@mansr.com> - 2016-01-11 22:10 +0100
                              Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-11 22:20 +0100
                                [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig Borislav Petkov <bp@suse.de> - 2016-01-14 19:50 +0100
                                  Re: [RFC PATCH] x86/kconfig: Sanity-check config file during  oldconfig Thomas Voegtle <tv@lio96.de> - 2016-01-18 14:40 +0100
                                    Re: [RFC PATCH] x86/kconfig: Sanity-check config file during  oldconfig Borislav Petkov <bp@suse.de> - 2016-01-18 15:10 +0100
                                      Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig Måns Rullgård <mans@mansr.com> - 2016-01-18 15:20 +0100
                                        Re: [RFC PATCH] x86/kconfig: Sanity-check config file during  oldconfig Borislav Petkov <bp@suse.de> - 2016-01-18 15:30 +0100
                                        Re: [RFC PATCH] x86/kconfig: Sanity-check config file during  oldconfig Borislav Petkov <bp@suse.de> - 2016-01-18 15:50 +0100
                                          Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig Måns Rullgård <mans@mansr.com> - 2016-01-18 16:00 +0100
                                            Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig Måns Rullgård <mans@mansr.com> - 2016-01-18 16:50 +0100
                                            Re: [RFC PATCH] x86/kconfig: Sanity-check config file during  oldconfig Borislav Petkov <bp@suse.de> - 2016-01-18 16:50 +0100
                                  [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
                            Re: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-11 22:10 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1306707

On Mon, Jan 11, 2016 at 09:04:45PM +0000, Måns Rullgård wrote:
> What do modules have to do with anything?

I'm trying to address Markus' case where he spoke of having modules off
and building everything into the kernel. But CONFIG_MODULES is wrong
here, I'm not going to grep for it. As I said, I'll have to think about
it more.

-- 
Regards/Gruss,
    Boris.

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

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

#1309567 — [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

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.

The other useful thing with this solution is that it can be extended to
other config file sanity-checking, should the need arise.

Reported-by: Thomas Voegtle <tv@lio96.de>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Måns Rullgård <mans@mansr.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/scripts/check-configs.sh | 44 +++++++++++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile          |  3 +++
 2 files changed, 47 insertions(+)
 create mode 100644 arch/x86/scripts/check-configs.sh

diff --git a/arch/x86/scripts/check-configs.sh b/arch/x86/scripts/check-configs.sh
new file mode 100644
index 000000000000..775d07e37df5
--- /dev/null
+++ b/arch/x86/scripts/check-configs.sh
@@ -0,0 +1,44 @@
+#!/bin/bash
+
+if [ "$1" != "oldconfig" ]; then
+	exit 0
+fi
+
+srctree=$2
+ARCH="$3"
+UNAME_RELEASE=$(uname -r)
+
+CONFIGS=".config /lib/modules/$UNAME_RELEASE/.config /etc/kernel-config /boot/config-$UNAME_RELEASE"
+
+if [ "$ARCH" = "X86_32" ]; then
+	CONFIGS="$CONFIGS $srctree/arch/x86/configs/i386_defconfig"
+else
+	CONFIGS="$CONFIGS $srctree/arch/x86/configs/x86_64_defconfig"
+fi
+
+for c in $CONFIGS;
+do
+	if [ -e $c ]; then
+		OLD_CONFIG=$c
+		break
+	fi
+done
+
+if [ -z "$OLD_CONFIG" ]; then exit 0; fi
+
+# Check optimal microcode loader .config settings
+if ! grep -v "^#" $OLD_CONFIG | grep -q MICROCODE; then
+	exit 0
+fi
+
+MSG="\nYou have CONFIG_MICROCODE enabled without BLK_DEV_INITRD. The preferred\n\
+way is to enable it and make sure microcode is added to your initrd as\n\
+explained in Documentation/x86/early-microcode.txt. This is also the\n\
+most tested method as the majority of distros do it. Alternatively, and\n\
+if you don't want to enable modules, you should make sure the microcode\n\
+is built into the kernel.\n"
+
+if ! grep -v "^#" $OLD_CONFIG | grep -q BLK_DEV_INITRD; then
+	echo -e $MSG
+	read -p "Press any key... "
+fi
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index d79cba4ce3eb..136ae9744efc 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -81,6 +81,9 @@ simple-targets := oldconfig allnoconfig allyesconfig allmodconfig \
 PHONY += $(simple-targets)
 
 $(simple-targets): $(obj)/conf
+ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/scripts/check-configs.sh),)
+	$(Q)$(CONFIG_SHELL) $(srctree)/arch/$(SRCARCH)/scripts/check-configs.sh $@ $(srctree) $(ARCH)
+endif
 	$< $(silent) --$@ $(Kconfig)
 
 PHONY += oldnoconfig savedefconfig defconfig
-- 
2.3.5

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

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

#1311553 — Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

[Multipart message — attachments visible in raw view] — view raw

On Thu, 14 Jan 2016, Borislav Petkov 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.
>
> The other useful thing with this solution is that it can be extended to
> other config file sanity-checking, should the need arise.
>
> Reported-by: Thomas Voegtle <tv@lio96.de>
> Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
> Cc: Måns Rullgård <mans@mansr.com>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> ---
> arch/x86/scripts/check-configs.sh | 44 +++++++++++++++++++++++++++++++++++++++
> scripts/kconfig/Makefile          |  3 +++
> 2 files changed, 47 insertions(+)
> create mode 100644 arch/x86/scripts/check-configs.sh
>
> diff --git a/arch/x86/scripts/check-configs.sh b/arch/x86/scripts/check-configs.sh
> new file mode 100644
> index 000000000000..775d07e37df5
> --- /dev/null
> +++ b/arch/x86/scripts/check-configs.sh
> @@ -0,0 +1,44 @@
> +#!/bin/bash
> +
> +if [ "$1" != "oldconfig" ]; then
> +	exit 0
> +fi
> +
> +srctree=$2
> +ARCH="$3"
> +UNAME_RELEASE=$(uname -r)
> +
> +CONFIGS=".config /lib/modules/$UNAME_RELEASE/.config /etc/kernel-config /boot/config-$UNAME_RELEASE"
> +
> +if [ "$ARCH" = "X86_32" ]; then
> +	CONFIGS="$CONFIGS $srctree/arch/x86/configs/i386_defconfig"
> +else
> +	CONFIGS="$CONFIGS $srctree/arch/x86/configs/x86_64_defconfig"
> +fi
> +
> +for c in $CONFIGS;
> +do
> +	if [ -e $c ]; then
> +		OLD_CONFIG=$c
> +		break
> +	fi
> +done
> +
> +if [ -z "$OLD_CONFIG" ]; then exit 0; fi
> +
> +# Check optimal microcode loader .config settings
> +if ! grep -v "^#" $OLD_CONFIG | grep -q MICROCODE; then
> +	exit 0
> +fi
> +
> +MSG="\nYou have CONFIG_MICROCODE enabled without BLK_DEV_INITRD. The preferred\n\
> +way is to enable it and make sure microcode is added to your initrd as\n\
> +explained in Documentation/x86/early-microcode.txt. This is also the\n\
> +most tested method as the majority of distros do it. Alternatively, and\n\
> +if you don't want to enable modules, you should make sure the microcode\n\
> +is built into the kernel.\n"
> +
> +if ! grep -v "^#" $OLD_CONFIG | grep -q BLK_DEV_INITRD; then
> +	echo -e $MSG
> +	read -p "Press any key... "
> +fi
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index d79cba4ce3eb..136ae9744efc 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -81,6 +81,9 @@ simple-targets := oldconfig allnoconfig allyesconfig allmodconfig \
> PHONY += $(simple-targets)
>
> $(simple-targets): $(obj)/conf
> +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/scripts/check-configs.sh),)
> +	$(Q)$(CONFIG_SHELL) $(srctree)/arch/$(SRCARCH)/scripts/check-configs.sh $@ $(srctree) $(ARCH)
> +endif
> 	$< $(silent) --$@ $(Kconfig)
>
> PHONY += oldnoconfig savedefconfig defconfig
>


My problem was, CONFIG_MICROCODE got dropped silently, and yes that is
fixed for me with this patch.
But I think this is a little bit odd way to fix it, but I don't have a 
better idea.

What's with olddefconfig and silentoldconfig ?

btw that patch has to go to stable 4.4, too


   Thomas

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

#1311572 — Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

On Mon, Jan 18, 2016 at 02:36:09PM +0100, Thomas Voegtle wrote:
> My problem was, CONFIG_MICROCODE got dropped silently, and yes that is
> fixed for me with this patch. But I think this is a little bit odd way
> to fix it, but I don't have a better idea.

Me neither. The problem is, I need to grep the config that goes into
the "oldconfig" *before* scripts/kconfig/conf gets a hold of it and
satisfies deps and thus turns off CONFIG_MICROCODE in the process. This
is a simpler solution short of hacking scripts/kconfig/conf and it can
be used for other stuff we might need in arch/x86/

> What's with olddefconfig

Yes, I'll update the patch.

> and silentoldconfig ?

This one is funny. Makefile's help says:

  silentoldconfig - Same as oldconfig, but quietly, additionally update deps

and yet doing

$ make silentoldconfig

is not very silent and goes through all new prompts asking me about them.

Regarding this issue, yes, I'll add its name to the script too.

> btw that patch has to go to stable 4.4, too

Sure, once we agree on the approach.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

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

#1311577 — Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

Borislav Petkov <bp@suse.de> writes:

> On Mon, Jan 18, 2016 at 02:36:09PM +0100, Thomas Voegtle wrote:
>> My problem was, CONFIG_MICROCODE got dropped silently, and yes that is
>> fixed for me with this patch. But I think this is a little bit odd way
>> to fix it, but I don't have a better idea.
>
> Me neither. The problem is, I need to grep the config that goes into
> the "oldconfig" *before* scripts/kconfig/conf gets a hold of it and
> satisfies deps and thus turns off CONFIG_MICROCODE in the process. 

Wasn't the idea *not* to disable CONFIG_MICROCODE?

> This is a simpler solution short of hacking scripts/kconfig/conf and
> it can be used for other stuff we might need in arch/x86/
>
>> What's with olddefconfig
>
> Yes, I'll update the patch.
>
>> and silentoldconfig ?
>
> This one is funny. Makefile's help says:
>
>   silentoldconfig - Same as oldconfig, but quietly, additionally update deps
>
> and yet doing
>
> $ make silentoldconfig
>
> is not very silent and goes through all new prompts asking me about them.

It asks about new options but doesn't print (as many) unchanged ones.
That makes it more silent.  olddefconfig asks no questions and sets new
options to their defaults.

-- 
Måns Rullgård

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

#1311579 — Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

On Mon, Jan 18, 2016 at 02:11:49PM +0000, Måns Rullgård wrote:
> It asks about new options but doesn't print (as many) unchanged ones.
> That makes it more silent.

So it should be called

make moresilentoldconfigbutnotcompletelyconfig

or so.

-- 
Regards/Gruss,
    Boris.

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

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

#1311592 — Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

On Mon, Jan 18, 2016 at 02:11:49PM +0000, Måns Rullgård wrote:
> Wasn't the idea *not* to disable CONFIG_MICROCODE?

Is the error message not understandable?

+MSG="\nYou have CONFIG_MICROCODE enabled without BLK_DEV_INITRD. The preferred\n\
+way is to enable it and make sure microcode is added to your initrd as\n\
+explained in Documentation/x86/early-microcode.txt. This is also the\n\
+most tested method as the majority of distros do it. Alternatively, and\n\
+if you don't want to enable modules, you should make sure the microcode\n\
+is built into the kernel.\n"

-- 
Regards/Gruss,
    Boris.

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

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

#1311596 — Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

Borislav Petkov <bp@suse.de> writes:

> On Mon, Jan 18, 2016 at 02:11:49PM +0000, Måns Rullgård wrote:
>> Wasn't the idea *not* to disable CONFIG_MICROCODE?
>
> Is the error message not understandable?
>
> +MSG="\nYou have CONFIG_MICROCODE enabled without BLK_DEV_INITRD. The preferred\n\
> +way is to enable it and make sure microcode is added to your initrd as\n\
> +explained in Documentation/x86/early-microcode.txt. This is also the\n\
> +most tested method as the majority of distros do it. Alternatively, and\n\
> +if you don't want to enable modules, you should make sure the microcode\n\
> +is built into the kernel.\n"

I understand and disagree.  I think you're being overzealous in trying
to bludgeon people into doing things the way you think they should be
done.

From the point of view of the actual update mechanism, what difference
does it make where the microcode data was retrieved from?  If you want
to warn about what you consider "unsafe" updates, do that when the
update happens instead.  With this patch, simply enabling BLK_DEV_INITRD
will shut up the warning even if an initrd is never actually used.
Also, what do modules have to do with anything?

-- 
Måns Rullgård

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

#1311620 — Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

Borislav Petkov <bp@suse.de> writes:

> On Mon, Jan 18, 2016 at 02:51:00PM +0000, Måns Rullgård wrote:
>> I understand and disagree.  I think you're being overzealous in trying
>> to bludgeon people into doing things the way you think they should be
>> done.
>
> So I did explain why it is better to do microcode updates from the
> initrd. And nowhere in that explanation I am "bludgeoning" people into
> doing things the way I want. Which is silly, I'd never even *think* of
> wanting to do that - I have enough other shit to deal with.

Forcing users to press a damn key on the keyboard after your pointless
warning message sure feels like bludgeoning to me.

>> From the point of view of the actual update mechanism, what difference
>> does it make where the microcode data was retrieved from?  If you want
>> to warn about what you consider "unsafe" updates, do that when the
>> update happens instead.  With this patch, simply enabling BLK_DEV_INITRD
>> will shut up the warning even if an initrd is never actually used.
>> Also, what do modules have to do with anything?
>
> This reads like your mail from a couple of days ago. Which leads me to
> think that you haven't understood at all what I've been writing this
> whole time.

Clearly you didn't explain it very well.

-- 
Måns Rullgård

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

#1311626 — Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig

On Mon, Jan 18, 2016 at 02:51:00PM +0000, Måns Rullgård wrote:
> I understand and disagree.  I think you're being overzealous in trying
> to bludgeon people into doing things the way you think they should be
> done.

So I did explain why it is better to do microcode updates from the
initrd. And nowhere in that explanation I am "bludgeoning" people into
doing things the way I want. Which is silly, I'd never even *think* of
wanting to do that - I have enough other shit to deal with.

But I guess you're reading it the way you wanna read it so I'm going to
leave you thinking whatever you want to think.

> From the point of view of the actual update mechanism, what difference
> does it make where the microcode data was retrieved from?  If you want
> to warn about what you consider "unsafe" updates, do that when the
> update happens instead.  With this patch, simply enabling BLK_DEV_INITRD
> will shut up the warning even if an initrd is never actually used.
> Also, what do modules have to do with anything?

This reads like your mail from a couple of days ago. Which leads me to
think that you haven't understood at all what I've been writing this
whole time.

So I'm going to stop wasting time with you.

-- 
Regards/Gruss,
    Boris.

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

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

#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] | [prev] | [next] | [standalone]

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

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 — 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> 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 — Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig)

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 — Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig)

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 — 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> 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 — Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig)

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]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web