linux-kernel - Re: [patch 05/11] [PATCH 05/11] x86: Moved microcode.c to microcode

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]

Date:	Fri, 19 Sep 2008 15:52:53 +0200
From:	"Giacomo A. Catenazzi" <cate@...ian.org>
To:	Peter Oruba <peter.oruba@....com>
CC:	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch 05/11] [PATCH 05/11] x86: Moved microcode.c to microcode_intel.c.

Peter Oruba wrote:
> Giacomo A. Catenazzi schrieb:
>> Dmitry Adamushko wrote:
>>> 2008/9/19 Peter Oruba <peter.oruba@....com>:
>>>> Some additonal words regarding the current user space issues:
>>>>
>>>> IMHO the most convenient way to update microcode is through the
>>>> firmware loading
>>>> interface instead of microcode_ctl. This reduces user-space
>>>> responsibilities to
>>>> loading the correct module at boot time and to place the microcode
>>>> patch file at
>>>> the right location via package installation. The problems mentioned
>>>> in this
>>>> thread would then probably disappear as well. What do you guys think?
>>> It'd still require changes for all the setups that currently rely on
>>> the 'microcode_ctl' interface. Moreover, Arjan's setup failed not due
>>> to the 'microcode_ctl' per se but due to the altered kernel module
>>> name. After all, we can't break the established interface this way.
>>>
>>> We can either reserve 'microcode' as a legacy name for intel cpus (==
>>> microcode_intel), or maybe we can use request_module() from
>>> microcode.ko to load a proper arch-specific module (I guess, it's not
>>> ok for !KMOD-enabled kernels).
>> I agree. A wrapper "microcode.ko" module would be nice, in order
>> to allow independent kernel and user space upgrades.
>>
>> The module name is important also on udev method: only a module
>> load triggers the microcode request in udev, thus also the
>> new method should have stable kernel module name.
>>
>> ciao
>>     cate
>>
> 
> That sounds like a single-module solution would be the best way to go. All
> dependencies would then be handled inside the module.

Single module probably is more difficult to maintain.

I was thinking about a very simple additional module:
Check the cpu: load the relevant module, and wrapper the calls to the
relevant module.

So every vendor could develop easier the own driver. Only the interface
should be stable.

Eventually we could solve it in the distribution scripts (using module
aliases), but it would be kernel version dependent, and it would works
only on the new method (or a new microcode_ctl version, but people
upgrade more often kernel than packages).

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/