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] [day] [month] [year] [list]
Date:	Fri, 13 Mar 2009 09:37:11 +0100
From:	"Giacomo A. Catenazzi" <cate@...ian.org>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Linux* Processor Microcode Data File

Arjan van de Ven wrote:
> On Thu, 12 Mar 2009 11:03:11 +0100
> "Giacomo A. Catenazzi" <cate@...eee.net> wrote:
> 
>>> there are various cases where microcode is needed (for example, when
>>> you hotplug a new cpu); request_firmware() is just the right way to
>>> do such things, and an initscript is just the wrong way
>> I don't agree ;-)
>> I agree that request_firmware method is better than init.d scripts,
>> but not that it is the right things. microcodes should be loaded at
>> very beginning of boot process, so by BIOS, by GRUB or on hotpug
>> event by request_firmware.
> 
> ... and how do you do CPU hotplug then ?

and system that doesn't use GRUB vX.Y, and ...

The driver in kernel should remain, for hotplug (CPU not completely
initialized) and for the other cases.

But my argument is that microcode loading in kernel, in "other cases"
is not optimal.
IIRC Intel documentation recommends to update microcodes in BIOS
(before full initialize all registers).

Anyway the "GRUB" proposal will be as an additional way, like BIOS
update: try to load microcode earlier as possible. The worse case
will be done very late, at new package installation time.

But now I've an other doubt:
Users asked me for a script that check and update microcode as
cronjob (I hope nobody will use extreme short "polling" periods to
Intel server.).
Updating microcode at full running time is not supported by
update_firmware method, right?
Is it the correct bahaviour? (according the "load earlier" I think
yes, but maybe I miss something)

>> BTW: why do we have microcode loading modular?
> 
> only the legacy initscript part is modular afaik.

ok

ciao
	cate
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ