linux-kernel - Re: Intel Microcode loader, tg3 driver, and the -rc8-mmotd New World Order firmware...

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:	Thu, 03 Jul 2008 11:42:56 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	Valdis.Kletnieks@...edu, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, jonathan@...masters.org,
	Shaohua Li <shaohua.li@...el.com>, greg@...ah.com,
	arjan@...radead.org
Subject: Re: Intel Microcode loader, tg3 driver, and the -rc8-mmotd New
	World Order firmware...

On Thu, 2008-07-03 at 12:22 +0200, Kay Sievers wrote:
> So, maybe a:
>   # rewrite firmware file name to all-in-one Intel CPU microcode data file
>   SUBSYSTEM=="firmware", ENV{FIRMWARE}=="intel-ucode/*", ENV{FIRMWARE}="intel-ucode/microcode.dat"
> would be enough?

Nah, it needs the binary form. The actual 'microcode.dat' just looks
like this...

0x00000001,     0x00000013,     0x02062001,     0x00000683,
0x2f0da1b0,     0x00000001,     0x00000001,     0x00000000,
0x00000000,     0x00000000,     0x00000000,     0x00000000,
0xbf5ad468,     0xc79f5237,     0xbd53889e,     0x896bfd13,
0x7adc0c8f,     0x44e9e0bc,     0x1a331fc9,     0x00b0f479,

That's all microcode_ctl actually does; read in the text file and output
the (complete) binary. Hence:
      /sbin/microcode_ctl -f "$DIR/microcode.dat" -d /sys$DEVPATH/data

At a later date, we could make userspace output only the part for the
desired CPU, and rip out the kernel-side code which searches for it
within the big blob. That was presumably the intention in the commit
which changed things. But then again, the kernel-side code still needs
to do a certain amount of sanity checking on what it receives -- so I'm
not sure we gain a huge amount by trying to remove that functionality
from the kernel (not that I've looked hard at the line count).

If we're _not_ going to make userspace provide only what's required, and
we keep the selection code in the kernel, then I don't see the point in
having separate firmware filenames for different cpus. We could just
change the driver to call request_firmware("intel-microcode.bin") and do
this one-off conversion:
	touch /lib/firmware/intel-microcode.bin
	microcode_ctl -d /lib/firmware/intel-microcode.bin

-- 
dwmw2

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