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 13:32:07 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	David Woodhouse <dwmw2@...radead.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 11:42 +0100, David Woodhouse wrote:
> 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...

Ah, I see.

> 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).

I think, the in-kernel selection logic is nice, people can still
provide a custom .bin file which contains only the needed code for the
actual CPU, and it will not really do any "search", right?

> 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

Sounds fine, yeah. With the in-kernel search, we should make the file
just a name without the CPU id. This would also make it easier to find
and include the fw into the kernel, right?

We could always export the CPU id somewhere else, so "advanced" tools
could look it up in sysfs and upload in a "custom" way. I don't think
anybody will really need that. :)

Thanks,
Kay

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