linux-kernel - Re: microcode loading got really slow.

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: <s5hbo81viq4.wl%tiwai@suse.de>
Date:	Thu, 23 May 2013 17:06:27 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Dave Jones <davej@...hat.com>
Cc:	Ming Lei <tom.leiming@...il.com>, "H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>, x86@...nel.org,
	fenghua.yu@...el.com
Subject: Re: microcode loading got really slow.

At Thu, 23 May 2013 10:48:00 -0400,
Dave Jones wrote:
> 
> On Thu, May 23, 2013 at 04:36:20PM +0200, Takashi Iwai wrote:
>  
>  > > >> Also udev supports user-defined rules to load firmware, which
>  > > >> means some drivers may not put their firmware in the default
>  > > >> path of distribution's firmware.
>  > > >
>  > > > It's why I suggested to put a warning in that path as the first step.
>  > > > So we can see whether there is any actual user.
>  > > 
>  > > If you plan to do it, it'd better to add default firmware path of some
>  > > distributions into firmware_class.c first, otherwise it may cause
>  > > unnecessary noise for this distribution.
>  > >
>  > > But if more default search paths are added, it might cause mistaken
>  > > firmwares found under incorrect path, for example, android's
>  > > default path is "/etc/firmware" and "/vendor/firmware"(maybe different
>  > > for different versions).
>  > > 
>  > > Also, putting default search paths into kernel isn't good, which was
>  > > introduced unwillingly for well-known reason.
>  > 
>  > Maybe we can create a new Kconfig to specify non-standard firmware
>  > path?
> 
> You keep mentioning non-standard paths for firmware, but in this case,
> I don't think Fedora is doing anything unusual.  We have microcode firmware
> in /lib/firmware/intel-ucode/ just like (afaik) everyone else.
> 
> What *is* happening, I think is that the CPU is new enough that there's no
> newer firmware file available for it. 
> 
> thoughts?

Yes, in your case, everything is fine in the kernel itself.  And no
microcode update is needed for new CPU, thus no firmware.

The problem is that the f/w loader tries to call udev and udev gets
stuck when invoked from module init.  This doesn't hit most drivers
because usually the firmware is mandatory and it must exist.  Thus the
direct f/w loading always works for them.  If it hits, it's only the
error case.

But, for the microcode loader, it's normal that the firmware doesn't
exist, like your case.  Unfortunately, this falls back to user helper
mode, and now you're seeing the problem.

So, the option would be to fix udev, let it behaving like before.
The second option would be to change ("fix") the kernel behavior, but
the question is which way.


Takashi


> 	Dave
> 
--
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/