linux-kernel - Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b647ffbd0911120748q6e3ddcf9h31b48972aff9e39c@mail.gmail.com>
Date:	Thu, 12 Nov 2009 16:48:34 +0100
From:	Dmitry Adamushko <dmitry.adamushko@...il.com>
To:	Andreas Herrmann <herrmann.der.user@...glemail.com>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>, Mike Travis <travis@....com>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <borislav.petkov@....com>,
	Andreas Mohr <andi@...as.de>, Jack Steiner <steiner@....com>
Subject: Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output 
	messages

2009/11/12 Andreas Herrmann <herrmann.der.user@...glemail.com>:
> On Thu, Nov 12, 2009 at 01:06:36PM +0100, Dmitry Adamushko wrote:
>> 2009/11/12 Dmitry Adamushko <dmitry.adamushko@...il.com>:
>> > 2009/11/12 Ingo Molnar <mingo@...e.hu>:
>> >>
>> >> -tip testing found the following bug - there's a _long_ boot delay of
>> >> 58.6 seconds if the CPU family is not supported:
>> >>
>> >> [    1.421761] calling  microcode_init+0x0/0x137 @ 1
>> >> [    1.426532] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
>> >> [   61.433126] microcode: failed to load file amd-ucode/microcode_amd.bin
>> >> [   61.439682] microcode: CPU0: AMD CPU family 0xf not supported
>> >> [   61.445441] microcode: CPU1: AMD CPU family 0xf not supported
>> >> [   61.451273] Microcode Update Driver: v2.00 <tigran@...azian.fsnet.co.uk>, Peter Oruba
>> >> [   61.459116] initcall microcode_init+0x0/0x137 returned 0 after 58625622 usecs
>> >>
>> >> Where does this delay come from?
>> >
>> > My guess is that it's comming from
>> >
>> > static int loading_timeout = 60;        /* In seconds */
>> >
>> > drivers/base/firmware_class.c
>> >
>> > given that you seem to have MICROCODE build in kernel, so this patch
>> > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commit;h=d1c84f79a6ba992dc01e312c44a21496303874d6
>> >
>> > will result in sending a request for a firmware image to user-space
>> > (unless that firmware image is also built-in into the kernel) and
>> > user-space has not started yet.
>>
>> btw., it doesn't make sense for request_firmware() to even try this if
>> the system_state != SYSTEM_RUNNING and current == 'init' (it'd perhaps
>> make some sense if it's been done in a context of another task -- like
>> in case of a parallel boot).
>
>> And perhaps it just makes sense for microcode to use request_firmware_nowait().
>
> That would be asynchronous.

What I had in mind is as follows:

request_firmware_nowait() sends an async request which can be
preserved (and this is an assumption -- I haven't really verified it
yet) until some latter stage when user-space has been started and is
capable of handling (cached) firmware-load requests. I may be (and
perhaps I'm) wrong with the above assumption and the solution is
either never build such a module into the kernel or only do it with
built-in firmware blobs.


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