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: x86/microcode update on systems without INITRD Borislav Petkov <bp@suse.de> - 2016-01-11 22:10 +0100

Page 1 of 2  [1] 2  Next page →

#1303523 — Re: x86/microcode update on systems without INITRD

On Thu, Jan 07, 2016 at 01:12:16PM +0100, Thomas Voegtle wrote:
> I just diffed my 4.3 config with the 4.4 config and saw that the whole
> Microcode stuff was silently dropped by a normal "make oldconfig".

Can you send me that 4.3 config please?

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1303564

On 2016.01.07 at 13:36 +0100, Thomas Voegtle wrote:
> On Thu, 7 Jan 2016, Borislav Petkov wrote:
> 
> >On Thu, Jan 07, 2016 at 01:12:16PM +0100, Thomas Voegtle wrote:
> >>I just diffed my 4.3 config with the 4.4 config and saw that the whole
> >>Microcode stuff was silently dropped by a normal "make oldconfig".
> >
> >Can you send me that 4.3 config please?
> 
> Attached. It is a little bit unusual config without modules etc.
> 
> But doesn't dropping Microcde stuff in the config happen to anyone who
> hasn't INITRD stuff switched on?

Yes. But, as I wrote above, if you simply drop the BLK_DEV_INITRD
dependency, it will work just fine. 
I also don't use modules and the firmware gets applied at boot time.

...
[    2.573261] EDAC amd64: MCT channel count: 2
[    2.573401] EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV 0000:00:18.2 (INTERRUPT)
[    2.573414] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED)
[    2.573424] hidraw: raw HID events driver (C) Jiri Kosina
[    2.573449] usbcore: registered new interface driver usbhid
[    2.573449] usbhid: USB HID core driver
[    2.573770] usbcore: registered new interface driver snd-usb-audio
[    2.573786] Netfilter messages via NETLINK v0.30.
[    2.573797] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[    2.573966] ctnetlink v0.93: registering with nfnetlink.
[    2.574427] ip_tables: (C) 2000-2006 Netfilter Core Team
[    2.574477] NET: Registered protocol family 17
[    2.574487] 9pnet: Installing 9P2000 support
[    2.574717] microcode: CPU0: patch_level=0x010000db
[    2.574724] microcode: CPU1: patch_level=0x010000db
[    2.574731] microcode: CPU2: patch_level=0x010000db
[    2.574736] microcode: CPU3: patch_level=0x010000db
[    2.574761] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    2.574876] registered taskstats version 1
[    2.575132] Btrfs loaded
...

-- 
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1304311

On Thu, 7 Jan 2016, Markus Trippelsdorf wrote:

> On 2016.01.07 at 13:36 +0100, Thomas Voegtle wrote:
>> On Thu, 7 Jan 2016, Borislav Petkov wrote:
>>
>>> On Thu, Jan 07, 2016 at 01:12:16PM +0100, Thomas Voegtle wrote:
>>>> I just diffed my 4.3 config with the 4.4 config and saw that the whole
>>>> Microcode stuff was silently dropped by a normal "make oldconfig".
>>>
>>> Can you send me that 4.3 config please?
>>
>> Attached. It is a little bit unusual config without modules etc.
>>
>> But doesn't dropping Microcde stuff in the config happen to anyone who
>> hasn't INITRD stuff switched on?
>
> Yes. But, as I wrote above, if you simply drop the BLK_DEV_INITRD
> dependency, it will work just fine.


That's not an option for me.

For me this is a serious regression, when a normal make oldconfig silently 
drops a feature which I had switched on before.



   Thomas

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

#1304475

On 2016.01.08 at 12:18 +0000, Mike Keehan wrote:
> On Thu, 7 Jan 2016 13:41:11 +0100
> Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
> 
> > On 2016.01.07 at 13:36 +0100, Thomas Voegtle wrote:
> > > On Thu, 7 Jan 2016, Borislav Petkov wrote:
> > > 
> > > >On Thu, Jan 07, 2016 at 01:12:16PM +0100, Thomas Voegtle wrote:
> > > >>I just diffed my 4.3 config with the 4.4 config and saw that the
> > > >>whole Microcode stuff was silently dropped by a normal "make
> > > >>oldconfig".
> > > >
> > > >Can you send me that 4.3 config please?
> > > 
> > > Attached. It is a little bit unusual config without modules etc.
> > > 
> > > But doesn't dropping Microcde stuff in the config happen to anyone
> > > who hasn't INITRD stuff switched on?
> > 
> > Yes. But, as I wrote above, if you simply drop the BLK_DEV_INITRD
> > dependency, it will work just fine. 
> > I also don't use modules and the firmware gets applied at boot time.
> > 
> > ...
> > [    2.573261] EDAC amd64: MCT channel count: 2
> > [    2.573401] EDAC MC0: Giving out device to module amd64_edac
> > controller F10h: DEV 0000:00:18.2 (INTERRUPT) [    2.573414] EDAC
> > PCI0: Giving out device to module amd64_edac controller EDAC PCI
> > controller: DEV 0000:00:18.2 (POLLED) [    2.573424] hidraw: raw HID
> > events driver (C) Jiri Kosina [    2.573449] usbcore: registered new
> > interface driver usbhid [    2.573449] usbhid: USB HID core driver
> > [    2.573770] usbcore: registered new interface driver snd-usb-audio
> > [    2.573786] Netfilter messages via NETLINK v0.30. [    2.573797]
> > nf_conntrack version 0.5.0 (65536 buckets, 262144 max) [    2.573966]
> > ctnetlink v0.93: registering with nfnetlink. [    2.574427]
> > ip_tables: (C) 2000-2006 Netfilter Core Team [    2.574477] NET:
> > Registered protocol family 17 [    2.574487] 9pnet: Installing 9P2000
> > support [    2.574717] microcode: CPU0: patch_level=0x010000db
> > [    2.574724] microcode: CPU1: patch_level=0x010000db
> > [    2.574731] microcode: CPU2: patch_level=0x010000db
> > [    2.574736] microcode: CPU3: patch_level=0x010000db
> > [    2.574761] microcode: Microcode Update Driver: v2.01
> > <tigran@aivazian.fsnet.co.uk>, Peter Oruba [    2.574876] registered
> > taskstats version 1 [    2.575132] Btrfs loaded
> > ...
> > 
> 
> I'm not sure what you mean by "drop the BLK_DEV_INITRD dependency",
> but my microcode does not get loaded unless I have BLK_DEV_INITRD=Y
> in my .config.
> 
> I don't use initrd, but I do use modules.

I mean:

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index db3622f22b61..52c6964e24bd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1126,7 +1126,6 @@ config MICROCODE
        bool "CPU microcode loading support"
        default y
        depends on CPU_SUP_AMD || CPU_SUP_INTEL
-       depends on BLK_DEV_INITRD
        select FW_LOADER
        ---help---

-- 
Markus

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

#1304534

On Thu, 7 Jan 2016 13:41:11 +0100
Markus Trippelsdorf <markus@trippelsdorf.de> wrote:

> On 2016.01.07 at 13:36 +0100, Thomas Voegtle wrote:
> > On Thu, 7 Jan 2016, Borislav Petkov wrote:
> > 
> > >On Thu, Jan 07, 2016 at 01:12:16PM +0100, Thomas Voegtle wrote:
> > >>I just diffed my 4.3 config with the 4.4 config and saw that the
> > >>whole Microcode stuff was silently dropped by a normal "make
> > >>oldconfig".
> > >
> > >Can you send me that 4.3 config please?
> > 
> > Attached. It is a little bit unusual config without modules etc.
> > 
> > But doesn't dropping Microcde stuff in the config happen to anyone
> > who hasn't INITRD stuff switched on?
> 
> Yes. But, as I wrote above, if you simply drop the BLK_DEV_INITRD
> dependency, it will work just fine. 
> I also don't use modules and the firmware gets applied at boot time.
> 
> ...
> [    2.573261] EDAC amd64: MCT channel count: 2
> [    2.573401] EDAC MC0: Giving out device to module amd64_edac
> controller F10h: DEV 0000:00:18.2 (INTERRUPT) [    2.573414] EDAC
> PCI0: Giving out device to module amd64_edac controller EDAC PCI
> controller: DEV 0000:00:18.2 (POLLED) [    2.573424] hidraw: raw HID
> events driver (C) Jiri Kosina [    2.573449] usbcore: registered new
> interface driver usbhid [    2.573449] usbhid: USB HID core driver
> [    2.573770] usbcore: registered new interface driver snd-usb-audio
> [    2.573786] Netfilter messages via NETLINK v0.30. [    2.573797]
> nf_conntrack version 0.5.0 (65536 buckets, 262144 max) [    2.573966]
> ctnetlink v0.93: registering with nfnetlink. [    2.574427]
> ip_tables: (C) 2000-2006 Netfilter Core Team [    2.574477] NET:
> Registered protocol family 17 [    2.574487] 9pnet: Installing 9P2000
> support [    2.574717] microcode: CPU0: patch_level=0x010000db
> [    2.574724] microcode: CPU1: patch_level=0x010000db
> [    2.574731] microcode: CPU2: patch_level=0x010000db
> [    2.574736] microcode: CPU3: patch_level=0x010000db
> [    2.574761] microcode: Microcode Update Driver: v2.01
> <tigran@aivazian.fsnet.co.uk>, Peter Oruba [    2.574876] registered
> taskstats version 1 [    2.575132] Btrfs loaded
> ...
> 

I'm not sure what you mean by "drop the BLK_DEV_INITRD dependency",
but my microcode does not get loaded unless I have BLK_DEV_INITRD=Y
in my .config.

I don't use initrd, but I do use modules.

Mike.

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

#1304371

On Thu, Jan 07, 2016 at 01:36:00PM +0100, Thomas Voegtle wrote:
> Attached. It is a little bit unusual config without modules etc.

Ok, I see it.

Please do a proper patch explaining why we're changing "depends on" to
"select" and we can try it, see who complains then and why.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

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

#1304390

Borislav Petkov <bp@suse.de> writes:

> On Thu, Jan 07, 2016 at 01:36:00PM +0100, Thomas Voegtle wrote:
>> Attached. It is a little bit unusual config without modules etc.
>
> Ok, I see it.
>
> Please do a proper patch explaining why we're changing "depends on" to
> "select" and we can try it, see who complains then and why.

Neither "depends on" nor "select" makes sense to me here.  The driver
apparently works without it, and simply having BLK_DEV_INITRD enabled
doesn't prevent improper (according to some people) use of the driver.
If updating microcode is inherently unsafe when a real disk is mounted,
the driver ought to detect this and refuse the operation (possibly with
an override option).

-- 
Måns Rullgård

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

#1304411

On Fri, Jan 08, 2016 at 11:18:51AM +0000, Måns Rullgård wrote:
> Neither "depends on" nor "select" makes sense to me here.  The driver
> apparently works without it,

The driver works without it if you build your microcode into the kernel.

There are use cases where building microcode into the kernel is *not* a
viable option so we have to support both builtin microcode and microcode
from the initrd.

> and simply having BLK_DEV_INITRD enabled doesn't prevent improper
> (according to some people) use of the driver. If updating microcode
> is inherently unsafe when a real disk is mounted, the driver ought
> to detect this and refuse the operation (possibly with an override
> option).

Huh, what?

-ENOPARSE.

-- 
Regards/Gruss,
    Boris.

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

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

#1304437

Borislav Petkov <bp@suse.de> writes:

> On Fri, Jan 08, 2016 at 11:18:51AM +0000, Måns Rullgård wrote:
>> Neither "depends on" nor "select" makes sense to me here.  The driver
>> apparently works without it,
>
> The driver works without it if you build your microcode into the kernel.
>
> There are use cases where building microcode into the kernel is *not* a
> viable option so we have to support both builtin microcode and microcode
> from the initrd.

How is an initrd different from a real filesystem as seen by the
microcode update driver?

>> and simply having BLK_DEV_INITRD enabled doesn't prevent improper
>> (according to some people) use of the driver. If updating microcode
>> is inherently unsafe when a real disk is mounted, the driver ought
>> to detect this and refuse the operation (possibly with an override
>> option).
>
> Huh, what?
>
> -ENOPARSE.

The objection against removing the dependency was that updating
microcode "late" isn't safe.  I don't see how turning on BLK_DEV_INITRD
stops anyone doing those allegedly unsafe updates anyway.

-- 
Måns Rullgård

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

#1304455

On Fri, Jan 08, 2016 at 11:46:28AM +0000, Måns Rullgård wrote:
> How is an initrd different from a real filesystem as seen by the
> microcode update driver?

For starters, initrd is available much earlier, even before paging is
enabled on 32-bit, for example. See find_cpio_data().

> The objection against removing the dependency was that updating
> microcode "late" isn't safe.  I don't see how turning on BLK_DEV_INITRD
> stops anyone doing those allegedly unsafe updates anyway.

No one is stopping anyone from doing late updates. It is a valid use
case, and we have to support it. And late updates are not necessarily
unsafe, per se.

Lemme put it this way: it is a lot less unproblematic to do early
updates. Mind you, there's no 100% guarantee that early updates would
always work either. It all depends on what the microcode patch does. But
they do work 99,9999999...% of the time. :)

IOW, I haven't heard of an early update breaking the machine. But it is
possible.

So the *general* flow should be that people enable BLK_DEV_INITRD,
put the microcode in there and it gets updated as early as possible.
This is what the distros do and it is the most tested path. The other
possibilities are there too, but only for cases where initrd is out of
the question.

I hope that makes it more clear.

-- 
Regards/Gruss,
    Boris.

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

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

#1304464

Borislav Petkov <bp@suse.de> writes:

> On Fri, Jan 08, 2016 at 11:46:28AM +0000, Måns Rullgård wrote:
>> How is an initrd different from a real filesystem as seen by the
>> microcode update driver?
>
> For starters, initrd is available much earlier, even before paging is
> enabled on 32-bit, for example. See find_cpio_data().

Yes, but the microcode driver doesn't care about this AFAICT.

>> The objection against removing the dependency was that updating
>> microcode "late" isn't safe.  I don't see how turning on BLK_DEV_INITRD
>> stops anyone doing those allegedly unsafe updates anyway.
>
> No one is stopping anyone from doing late updates. It is a valid use
> case, and we have to support it. And late updates are not necessarily
> unsafe, per se.

So it's meant to be supported, good.

> Lemme put it this way: it is a lot less unproblematic to do early
> updates. Mind you, there's no 100% guarantee that early updates would
> always work either. It all depends on what the microcode patch does. But
> they do work 99,9999999...% of the time. :)
>
> IOW, I haven't heard of an early update breaking the machine. But it is
> possible.
>
> So the *general* flow should be that people enable BLK_DEV_INITRD,
> put the microcode in there and it gets updated as early as possible.
> This is what the distros do and it is the most tested path. The other
> possibilities are there too, but only for cases where initrd is out of
> the question.

Yes, that's the common case, and those users will have BLK_DEV_INITRD
enabled anyway.  Now why should someone who, for whatever reasons, is
doing microcode updates late be forced to enable BLK_DEV_INITRD even
though he doesn't use it?

-- 
Måns Rullgård

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

#1304467

On 2016.01.08 at 13:08 +0100, Borislav Petkov wrote:
> On Fri, Jan 08, 2016 at 11:46:28AM +0000, Måns Rullgård wrote:
> > How is an initrd different from a real filesystem as seen by the
> > microcode update driver?
> 
> For starters, initrd is available much earlier, even before paging is
> enabled on 32-bit, for example. See find_cpio_data().
> 
> > The objection against removing the dependency was that updating
> > microcode "late" isn't safe.  I don't see how turning on BLK_DEV_INITRD
> > stops anyone doing those allegedly unsafe updates anyway.
> 
> No one is stopping anyone from doing late updates. It is a valid use
> case, and we have to support it. And late updates are not necessarily
> unsafe, per se.
> 
> Lemme put it this way: it is a lot less unproblematic to do early
> updates. Mind you, there's no 100% guarantee that early updates would
> always work either. It all depends on what the microcode patch does. But
> they do work 99,9999999...% of the time. :)
> 
> IOW, I haven't heard of an early update breaking the machine. But it is
> possible.
> 
> So the *general* flow should be that people enable BLK_DEV_INITRD,
> put the microcode in there and it gets updated as early as possible.
> This is what the distros do and it is the most tested path. The other
> possibilities are there too, but only for cases where initrd is out of
> the question.

But you take the choice away from people like me, who don't need initrd
at all. BLK_DEV_INITRD is a superfluous dependency in this case, because
microcode update works perfectly well without it.

-- 
Markus

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

#1304478

Borislav Petkov <bp@suse.de> writes:

> On Fri, Jan 08, 2016 at 01:16:01PM +0100, Markus Trippelsdorf wrote:
>> But you take the choice away from people like me, who don't need initrd
>> at all. BLK_DEV_INITRD is a superfluous dependency in this case, because
>> microcode update works perfectly well without it.
>
> Damn, you have a valid point too. I need to think about it...
>
> ... well, the only thing I can think of right now is to remove the
> dependency on BLK_DEV_INITRD completely - I believe this is what you
> proposed initially Markus - and add a BIG FAT SUGGESTION to Kconfig
> saying that people should strive for enabling early microcode loading if
> possible.

That seems perfectly reasonable to me.

-- 
Måns Rullgård

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

#1304482

On Fri, Jan 08, 2016 at 01:16:01PM +0100, Markus Trippelsdorf wrote:
> But you take the choice away from people like me, who don't need initrd
> at all. BLK_DEV_INITRD is a superfluous dependency in this case, because
> microcode update works perfectly well without it.

Damn, you have a valid point too. I need to think about it...

... well, the only thing I can think of right now is to remove the
dependency on BLK_DEV_INITRD completely - I believe this is what you
proposed initially Markus - and add a BIG FAT SUGGESTION to Kconfig
saying that people should strive for enabling early microcode loading if
possible.

This is the only way I see we can handle "make oldconfig" without
BLK_DEV_INITRD and microcode built-in into the kernel cases relatively
fair.

Hmmm.

Or I could hack "oldconfig" to issue that warning... Lemme think about
it and see how much Michal would scream at me for it. :-)

-- 
Regards/Gruss,
    Boris.

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

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

#1304503

On 2016-01-08 13:27, Borislav Petkov wrote:
> On Fri, Jan 08, 2016 at 01:16:01PM +0100, Markus Trippelsdorf wrote:
>> But you take the choice away from people like me, who don't need initrd
>> at all. BLK_DEV_INITRD is a superfluous dependency in this case, because
>> microcode update works perfectly well without it.
> 
> Damn, you have a valid point too. I need to think about it...
> 
> ... well, the only thing I can think of right now is to remove the
> dependency on BLK_DEV_INITRD completely - I believe this is what you
> proposed initially Markus - and add a BIG FAT SUGGESTION to Kconfig
> saying that people should strive for enabling early microcode loading if
> possible.
> 
> This is the only way I see we can handle "make oldconfig" without
> BLK_DEV_INITRD and microcode built-in into the kernel cases relatively
> fair.
> 
> Hmmm.
> 
> Or I could hack "oldconfig" to issue that warning... Lemme think about
> it and see how much Michal would scream at me for it. :-)

You can add a conditional comment like this

comment "WARNING: Early microcode loader requires initramfs support"
	depends on MICROCODE && !BLK_DEV_INITRD

and hope that somebody reads it.

Michal

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

#1304539

On Fri, Jan 08, 2016 at 01:48:40PM +0100, Michal Marek wrote:
> You can add a conditional comment like this
> 
> comment "WARNING: Early microcode loader requires initramfs support"
> 	depends on MICROCODE && !BLK_DEV_INITRD
> 
> and hope that somebody reads it.

Actually, I was thinking about something which gets printed when doing
"make oldconfig". In addition to the Kconfig text. I'll take a look once
the stupid cold goes away...

-- 
Regards/Gruss,
    Boris.

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

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

#1304620

On 2016-01-08 14:37, Borislav Petkov wrote:
> On Fri, Jan 08, 2016 at 01:48:40PM +0100, Michal Marek wrote:
>> You can add a conditional comment like this
>>
>> comment "WARNING: Early microcode loader requires initramfs support"
>> 	depends on MICROCODE && !BLK_DEV_INITRD
>>
>> and hope that somebody reads it.
> 
> Actually, I was thinking about something which gets printed when doing
> "make oldconfig". In addition to the Kconfig text.

The comments are printed during make oldconfig if a symbol in the
current menu needs updating. Which is probably not the case here, both
MICROCODE and BLK_DEV_INITRD are existing symbols.


> I'll take a look once
> the stupid cold goes away...

Oh, get well soon.

Michal

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

#1306632

On Fri, Jan 08, 2016 at 03:48:37PM +0100, Michal Marek wrote:
> The comments are printed during make oldconfig if a symbol in the
> current menu needs updating. Which is probably not the case here, both
> MICROCODE and BLK_DEV_INITRD are existing symbols.

Right, and the problem is that "make oldconfig" sees that BLK_DEV_INITRD
is not enabled in that case and disables CONFIG_MICROCODE too. So by the time
the comment gets evaluated, CONFIG_MICROCODE is off so no workie.

I tried a different thing, see below. It is a bit lengthly but it does
what it should and we can always extend it for other stuff later as it
might turn useful, according to my suspicion :-)

With Thomas' config it says:

$ make oldconfig
You have CONFIG_MICROCODE enabled without BLK_DEV_INITRD. Enable
it and make sure microcode is added to your initrd as explained in
Documentation/x86/early-microcode.txt

scripts/kconfig/Makefile:85: recipe for target 'oldconfig' failed
make[1]: *** [oldconfig] Error 1
Makefile:531: recipe for target 'oldconfig' failed
make: *** [oldconfig] Error 2


It needs to be made to look at CONFIG_MODULES and make that warning just
a hint. I'll have to think about it more...

Thoughts?

---
 arch/x86/scripts/check-configs.sh | 41 +++++++++++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile          |  3 +++
 2 files changed, 44 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..51ae9bde6965
--- /dev/null
+++ b/arch/x86/scripts/check-configs.sh
@@ -0,0 +1,41 @@
+#!/bin/bash
+
+if [ "$1" != "oldconfig" ]; then
+	exit 0
+fi
+
+srctree=$2
+ARCH="$3"
+UNAME_RELEASE=$(uname -r)
+
+KCONFIGS=".config /lib/modules/$UNAME_RELEASE/.config /etc/kernel-config /boot/config-$UNAME_RELEASE"
+
+if [ "$ARCH" = "X86_32" ]; then
+	KCONFIGS="$KCONFIGS $srctree/arch/x86/configs/i386_defconfig"
+else
+	KCONFIGS="$KCONFIGS $srctree/arch/x86/configs/x86_64_defconfig"
+fi
+
+for k in $KCONFIGS;
+do
+	if [ -e $k ]; then
+		OLD_CONFIG=$k
+		break
+	fi
+done
+
+if [ -z "$OLD_CONFIG" ]; then exit 0; fi
+
+# Check optimal microcode loader .config settings
+if ! grep -q MICROCODE $OLD_CONFIG; then
+	exit 0
+fi
+
+MSG="You have CONFIG_MICROCODE enabled without BLK_DEV_INITRD. Enable\n\
+it and make sure microcode is added to your initrd as explained in\n\
+Documentation/x86/early-microcode.txt\n"
+
+if ! grep -v "^#" $OLD_CONFIG | grep -q BLK_DEV_INITRD; then
+	echo -e $MSG
+	exit 1
+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]

#1306653

Borislav Petkov <bp@suse.de> writes:

> On Fri, Jan 08, 2016 at 03:48:37PM +0100, Michal Marek wrote:
>> The comments are printed during make oldconfig if a symbol in the
>> current menu needs updating. Which is probably not the case here, both
>> MICROCODE and BLK_DEV_INITRD are existing symbols.
>
> Right, and the problem is that "make oldconfig" sees that BLK_DEV_INITRD
> is not enabled in that case and disables CONFIG_MICROCODE too. So by the time
> the comment gets evaluated, CONFIG_MICROCODE is off so no workie.
>
> I tried a different thing, see below. It is a bit lengthly but it does
> what it should and we can always extend it for other stuff later as it
> might turn useful, according to my suspicion :-)
>
> With Thomas' config it says:
>
> $ make oldconfig
> You have CONFIG_MICROCODE enabled without BLK_DEV_INITRD. Enable
> it and make sure microcode is added to your initrd as explained in
> Documentation/x86/early-microcode.txt
>
> scripts/kconfig/Makefile:85: recipe for target 'oldconfig' failed
> make[1]: *** [oldconfig] Error 1
> Makefile:531: recipe for target 'oldconfig' failed
> make: *** [oldconfig] Error 2

But this is wrong.  Microcode update doesn't need initrd.

-- 
Måns Rullgård

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

#1306701

Borislav Petkov <bp@suse.de> writes:

> On Mon, Jan 11, 2016 at 08:29:01PM +0000, Måns Rullgård wrote:
>> But this is wrong.  Microcode update doesn't need initrd.
>
> You need to read my mail to the end:
>
>> It needs to be made to look at CONFIG_MODULES and make that warning
>> just a hint. I'll have to think about it more...

What do modules have to do with anything?

-- 
Måns Rullgård

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web