New format Intel microcode...

[Daniel J Blueman]

Hi Shao-hua,

Is the tool you mentioned last June [1] available for splitting up the
old firmware files to the new format (eg
/lib/firmware/intel-ucode/06-0d-06), or are updates available from
Intel (or otherwise) in this new format?

Thanks,
Dan

--- [1]

http://lwn.net/Articles/189377/
--
Daniel J Blueman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Shaohua Li]

On Thu, 2007-03-22 at 23:45 +0000, Daniel J Blueman wrote:
> Hi Shao-hua,
>
> Is the tool you mentioned last June [1] available for splitting up the
> old firmware files to the new format (eg
> /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> Intel (or otherwise) in this new format?

Yes, we are preparing the new format data files and maybe put it into a
new website. We will announce it when it's ready.

Thanks,
Shaohua

[Marcel Holtmann]

Hi Li,

> > Is the tool you mentioned last June [1] available for splitting up the
> > old firmware files to the new format (eg
> > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > Intel (or otherwise) in this new format?
> Yes, we are preparing the new format data files and maybe put it into a
> new website. We will announce it when it's ready.

please do _NOT_ use any sub-directories in the request_firmware() call.

Regards

Marcel

[Arjan van de Ven]

On Fri, 2007-03-23 at 10:43 +0100, Marcel Holtmann wrote:
> Hi Li,
>
> > > Is the tool you mentioned last June [1] available for splitting up the
> > > old firmware files to the new format (eg
> > > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > > Intel (or otherwise) in this new format?
> > Yes, we are preparing the new format data files and maybe put it into a
> > new website. We will announce it when it's ready.
>
> please do _NOT_ use any sub-directories in the request_firmware() call.

it's not a strictly a subdirectory; there is a slash in the "metaname"
the kernel asks for, and you can in userspace see it as subdirectory or
you don't.. that's entirely upto the userspace side :)

[Marcel Holtmann]

Hi Arjan,

> > > > Is the tool you mentioned last June [1] available for splitting up the
> > > > old firmware files to the new format (eg
> > > > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > > > Intel (or otherwise) in this new format?
> > > Yes, we are preparing the new format data files and maybe put it into a
> > > new website. We will announce it when it's ready.
> >
> > please do _NOT_ use any sub-directories in the request_firmware() call.
>
> it's not a strictly a subdirectory; there is a slash in the "metaname"
> the kernel asks for, and you can in userspace see it as subdirectory or
> you don't.. that's entirely upto the userspace side :)

that is the whole point. The slash was never meant to be used. It was
designed to take a filename or a pattern that will be later matched by
userspace. However some developers are now trying to abuse this since
the simple firmware helper script matches this directly to a filename
(and directory in this case) on the disk.

Putting a slash in the request_firmware() call now enforces a
subdirectory and that should be left up to the userspace. So the slash
is actually a forbidden character here.

Regards

Marcel

[Arjan van de Ven]

Marcel Holtmann wrote:
> that is the whole point. The slash was never meant to be used. It was
> designed to take a filename or a pattern that will be later matched by
> userspace. However some developers are now trying to abuse this since
> the simple firmware helper script matches this directly to a filename
> (and directory in this case) on the disk.
>
> Putting a slash in the request_firmware() call now enforces a
> subdirectory

I don't see how this follows from the former. Userspace is free to
translate the kernel string into anything it wants, even a simple
replacement of / with _. So I don't see how this "enforces" a
subdirectory. Firmware gets a namespace basically, and a / is a
logical namespace separator.

[Daniel J Blueman]

On 23/03/07, Shaohua Li <shaoh...@intel.com> wrote:
> On Thu, 2007-03-22 at 23:45 +0000, Daniel J Blueman wrote:
> > Hi Shao-hua,
> >
> > Is the tool you mentioned last June [1] available for splitting up the
> > old firmware files to the new format (eg
> > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > Intel (or otherwise) in this new format?
> Yes, we are preparing the new format data files and maybe put it into a
> new website. We will announce it when it's ready.

It's been a while; is there any sign of the ucode updates being
available, especially in light of the C2D/Q incorrect TLB invalidation
+ recent ucode to fix this?

Thanks again,
Daniel
--
Daniel J Blueman

[Andi Kleen]

"Daniel J Blueman" <daniel....@gmail.com> writes:

> On 23/03/07, Shaohua Li <shaoh...@intel.com> wrote:
> > On Thu, 2007-03-22 at 23:45 +0000, Daniel J Blueman wrote:
> > > Hi Shao-hua,
> > >
> > > Is the tool you mentioned last June [1] available for splitting up the
> > > old firmware files to the new format (eg
> > > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > > Intel (or otherwise) in this new format?
> > Yes, we are preparing the new format data files and maybe put it into a
> > new website. We will announce it when it's ready.
>
> It's been a while; is there any sign of the ucode updates being
> available, especially in light of the C2D/Q incorrect TLB invalidation
> + recent ucode to fix this?

That microcode update is not needed on any recent Linux kernel; it flushes
the TLBs in a way that is fine.

-Andi

[Bill Davidsen]

Andi Kleen wrote:
> "Daniel J Blueman" <daniel....@gmail.com> writes:
>
>> On 23/03/07, Shaohua Li <shaoh...@intel.com> wrote:
>>> On Thu, 2007-03-22 at 23:45 +0000, Daniel J Blueman wrote:
>>>> Hi Shao-hua,
>>>>
>>>> Is the tool you mentioned last June [1] available for splitting up the
>>>> old firmware files to the new format (eg
>>>> /lib/firmware/intel-ucode/06-0d-06), or are updates available from
>>>> Intel (or otherwise) in this new format?
>>> Yes, we are preparing the new format data files and maybe put it into a
>>> new website. We will announce it when it's ready.
>> It's been a while; is there any sign of the ucode updates being
>> available, especially in light of the C2D/Q incorrect TLB invalidation
>> + recent ucode to fix this?
>
> That microcode update is not needed on any recent Linux kernel; it flushes
> the TLBs in a way that is fine.
>

Slashdot carried an article this morning saying that an error in Intel
microcode was being fixed. However, it listed only Windows related sites
for the "fix" download. Is this the same TLB issue? And are these really
fixes for Windows to flush the TLB properly the way Linux does?

--
Bill Davidsen <davi...@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

[Arjan van de Ven]

(while I work for Intel this is not an official Intel statement, but
there is so much FUD going around now that I feel I need to at least
point out a few things others "forget")

> >
> Slashdot carried an article this morning saying that an error in Intel
> microcode was being fixed.

don't just always believe everything you read on slashdot please

> However, it listed only Windows related sites
> for the "fix" download. Is this the same TLB issue? And are these really
> fixes for Windows to flush the TLB properly the way Linux does?

First of all, Linux has microcode updates as well. Some of the more
hypish news-bulletins just conveniently "forgot" about this. Basically
all distributions ship them, so users who use the distro update tools
get these automatically. And the update mentioned has been shipping for
a while (in version 1.17).

Second, Intel really recommends always running the latest microcode.
(which is easy on Linux at least, and on Windows you can now see how
they do it). While reading the errata list may sound really scary, most
of the issues found and fixed are "lab finds" and are things operating
systems don't do. Some are more visible though; and since it's easy to
get the latest microcode (yum upgrade / apt-get upgrade / etc) you
probably are already running a recent one.

As for the TLB behavior; the Linux kernel is behaving correctly for
quite a while now as far as I know.. I wouldn't worry about it too much.
SMP tlb shootdown always has been tricky in the light of multiple cpus
having tlbs "hot" and active while tearing down mappings.
(just think about it: cpu0 is accessing the memory while cpu1 is
removing it; until you flush the tlb on cpu0 it won't see the new
pagetable state since the tlb is a cache...)

[Andi Kleen]

> Slashdot carried an article this morning saying that an error in Intel
> microcode was being fixed. However, it listed only Windows related sites

That's a little misleading. Always dangerous getting your information
from slashdot. Let's say Intel clarified some corner
cases in TLB flushing that have changed with Core2 and not everybody
got that right. I wouldn't say it was a Intel bug though.

> for the "fix" download. Is this the same TLB issue? And are these really

I think so.

> fixes for Windows to flush the TLB properly the way Linux does?

On newer Linux 2.6 yes. On 2.4/x86-64 you would need in theory the microcode
update too. (it'll probably show up at some point at the usual place
http://urbanmyth.org/microcode/). Linux/i386 is always fine.

But the problem is very obscure and you can likely ignore it too. If your
machine crashes it's very likely something else.

-Andi

[Chuck Ebbert]

On 06/28/2007 11:27 AM, Andi Kleen wrote:
>
> But the problem is very obscure and you can likely ignore it too. If your
> machine crashes it's very likely something else.

What about deliberate exploits of these bugs from userspace? Theo thinks
they are possible...

[Alex Riesen]

By any chance, do you known anything about microcode driver which
uses standard firmware load interfaces (like those used by wlan card)?
In particular, what format does the driver expect the microcode in?
It didn't accept Tigran's files in past, does it accept them now?

[Chuck Ebbert]

On 06/28/2007 10:12 AM, Arjan van de Ven wrote:
> (while I work for Intel this is not an official Intel statement, but
> there is so much FUD going around now that I feel I need to at least
> point out a few things others "forget")
>> Slashdot carried an article this morning saying that an error in Intel
>> microcode was being fixed.
>
> don't just always believe everything you read on slashdot please
>
>> However, it listed only Windows related sites
>> for the "fix" download. Is this the same TLB issue? And are these really
>> fixes for Windows to flush the TLB properly the way Linux does?
>
> First of all, Linux has microcode updates as well. Some of the more
> hypish news-bulletins just conveniently "forgot" about this. Basically
> all distributions ship them, so users who use the distro update tools
> get these automatically. And the update mentioned has been shipping for
> a while (in version 1.17).
>

Fedora 6 has version 1.13
Fedora 7 also has 1.13
RHEL 5 has 1.15
Debian stable has 1.15 (9 Oct 2006)
Suse 10.1 has 1.13

[Arjan van de Ven]

Chuck Ebbert wrote:
> On 06/28/2007 10:12 AM, Arjan van de Ven wrote:
>> (while I work for Intel this is not an official Intel statement, but
>> there is so much FUD going around now that I feel I need to at least
>> point out a few things others "forget")
>>> Slashdot carried an article this morning saying that an error in Intel
>>> microcode was being fixed.
>> don't just always believe everything you read on slashdot please
>>
>>> However, it listed only Windows related sites
>>> for the "fix" download. Is this the same TLB issue? And are these really
>>> fixes for Windows to flush the TLB properly the way Linux does?
>> First of all, Linux has microcode updates as well. Some of the more
>> hypish news-bulletins just conveniently "forgot" about this. Basically
>> all distributions ship them, so users who use the distro update tools
>> get these automatically. And the update mentioned has been shipping for
>> a while (in version 1.17).
>>
>
> Fedora 6 has version 1.13
> Fedora 7 also has 1.13

that's a fedora bug; we asked them to update it long ago in their
bugzilla. Maybe they updated the datafile, maybe they didn't. Be
careful with just looking at package version numbers, they don't per
se corresponds with versions of the data file.

> RHEL 5 has 1.15

be careful, it has the 1.17 datafile in the updates afaik.
but RH doesn't update the package version number.

same may or may not be true for the others, but if you only look at
package versions you don't get the datafile versions.

[Daniel J Blueman]

On 28/06/07, Chuck Ebbert <ceb...@redhat.com> wrote:
> On 06/28/2007 10:12 AM, Arjan van de Ven wrote:

[snip]

> >> However, it listed only Windows related sites
> >> for the "fix" download. Is this the same TLB issue? And are these really
> >> fixes for Windows to flush the TLB properly the way Linux does?
> >
> > First of all, Linux has microcode updates as well. Some of the more
> > hypish news-bulletins just conveniently "forgot" about this. Basically
> > all distributions ship them, so users who use the distro update tools
> > get these automatically. And the update mentioned has been shipping for
> > a while (in version 1.17).
>
> Fedora 6 has version 1.13
> Fedora 7 also has 1.13
> RHEL 5 has 1.15
> Debian stable has 1.15 (9 Oct 2006)
> Suse 10.1 has 1.13

You've got to give credit to Intel for providing the ucode updates though.

The Ubuntu/Debian microcode.ctl package fetches a new version upon
installation/reconfiguration [1]; I guess if there were ucode updates
that resolved stability/vulnerability issues with Linux, the security
team could release an updated package with new default microcode.

However, I think the package isn't installed per default in Ubuntu
7.04 ia32/x86-64...

Daniel

--- [1]

# dpkg-reconfigure microcode.ctl
Local microcode is old, you need an update.
Trying to download an new version of microcode.
Now attempting to download microcode.
microcode downloaded sucessfully
--
Daniel J Blueman

[Bill Davidsen]

Andi Kleen wrote:
>> Slashdot carried an article this morning saying that an error in Intel
>> microcode was being fixed. However, it listed only Windows related sites
>>
>
> That's a little misleading. Always dangerous getting your information
> from slashdot. Let's say Intel clarified some corner
> cases in TLB flushing that have changed with Core2 and not everybody
> got that right. I wouldn't say it was a Intel bug though.
>
>

Given that the Slashdot note was a pointer to Microsoft and echo of
their statements of a firmware fix, and that same information is on the
Microsoft site, I find it hard to find fault with them as a source for
pointers and some context on why they might be useful. If Intel has
released new microcode to address the issue, then it seems the code
didn't function as desired, and it doesn't matter what you call it.

>> for the "fix" download. Is this the same TLB issue? And are these really
>>
>
> I think so.
>
>

That was one question.

>> fixes for Windows to flush the TLB properly the way Linux does?
>>
>
> On newer Linux 2.6 yes. On 2.4/x86-64 you would need in theory the microcode
> update too. (it'll probably show up at some point at the usual place
> http://urbanmyth.org/microcode/). Linux/i386 is always fine.
>
> But the problem is very obscure and you can likely ignore it too. If your
> machine crashes it's very likely something else.
>

I don't ignore anything I can fix. An ounce of prevention is worth a
pound of cure. My systems don't currently crash, and that's the intended
behavior.

I was mainly concerned with this being a new issue, and curious if
Microsoft was calling an O/S bug a "microcode fix," given that the
average Windows user doesn't know microcode from nanotech anyway. The
non-answer from Arjan didn't answer either, and started by calling the
report FUD, implying that Slashdot was wrong (not about this), and
issuing so little answer and so much obfuscation that I thought he might
be running for President. ;-)

I'd like the microcode update, some people elsewhere speculate that user
level code could effect reliability if not security. I worry that an old
2.4 kernel would be an issue, even in kvm, if that were the case.

--
bill davidsen <davi...@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

[Arjan van de Ven]

> I was mainly concerned with this being a new issue, and curious if
> Microsoft was calling an O/S bug a "microcode fix," given that the
> average Windows user doesn't know microcode from nanotech anyway. The
> non-answer from Arjan didn't answer either, and started by calling the

then ask questions?
Linux 2.6 is not affected.. what more is there to say? Regardless of
that as I said, Intel recommends always running the most current
microcode.

> I'd like the microcode update, some people elsewhere speculate that user
> level code could effect reliability if not security.

those "people" are speculating. Simple as that.

(oh and the microcode update is already there as I said... so what's the
problem?)

--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

[Bill Davidsen]

Chuck Ebbert wrote:
> On 06/28/2007 11:27 AM, Andi Kleen wrote:
>> But the problem is very obscure and you can likely ignore it too. If your
>> machine crashes it's very likely something else.
>
> What about deliberate exploits of these bugs from userspace? Theo thinks
> they are possible...
>

Do you have any details? One of the folks in a chat was saying something
similar, but thought that causing as crash was the extent of it, rather
than any access violation. Obviously I don't know the extent of that
claim, so more information would be good.

--
Bill Davidsen <davi...@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

[Andi Kleen]

> I was mainly concerned with this being a new issue, and curious if
> Microsoft was calling an O/S bug a "microcode fix," given that the
> average Windows user doesn't know microcode from nanotech anyway. The
> non-answer from Arjan didn't answer either, and started by calling the
> report FUD, implying that Slashdot was wrong (not about this), and
> issuing so little answer and so much obfuscation that I thought he might
> be running for President. ;-)

Well you can read the Intel documentation if you want the whole story.
You can hardly expect a full introduction in the basics and then
subtle issues of TLB flushing in a quick email. You asked about opinions
and summaries and those you got.

> I'd like the microcode update,

It's called the "placebo effect" in the literature I believe.

> some people elsewhere speculate that user
> level code could effect reliability if not security.

speculate is the key word.

> I worry that an old
> 2.4 kernel would be an issue, even in kvm, if that were the case.

TLB flushing in virtualization works completely different. I doubt
it would be affected.

-Andi

[Arjan van de Ven]

On Mon, 2007-07-02 at 10:56 +0200, Alex Riesen wrote:

> On 3/23/07, Shaohua Li <shaoh...@intel.com> wrote:
> > On Thu, 2007-03-22 at 23:45 +0000, Daniel J Blueman wrote:
> > > Is the tool you mentioned last June [1] available for splitting up the
> > > old firmware files to the new format (eg
> > > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > > Intel (or otherwise) in this new format?
> > Yes, we are preparing the new format data files and maybe put it into a
> > new website. We will announce it when it's ready.
>

> Well, is it ready yet?
> -

you can use the old format still as well without any problems...

--
if you want to mail me at work (you don't), use arjan (at)
linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.org

-

[Alex Riesen]

Arjan van de Ven, Mon, Jul 02, 2007 19:18:29 +0200:

> On Mon, 2007-07-02 at 10:56 +0200, Alex Riesen wrote:
> > On 3/23/07, Shaohua Li <shaoh...@intel.com> wrote:
> > > On Thu, 2007-03-22 at 23:45 +0000, Daniel J Blueman wrote:
> > > > Is the tool you mentioned last June [1] available for splitting up the
> > > > old firmware files to the new format (eg
> > > > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > > > Intel (or otherwise) in this new format?
> > > Yes, we are preparing the new format data files and maybe put it into a
> > > new website. We will announce it when it's ready.
> >
> > Well, is it ready yet?
>

> you can use the old format still as well without any problems...
>

only with microcode utility. The microcode driver does not load it
through firmware helper.

It is by no means a problem. It's just there is this driver, which
tries to load its firmware, does not find it and complains about it in
logs... Just an annoying message in logs, that's all:

main: error loading '/lib/firmware/intel-ucode/06-09-05' for device \
'/devices/platform/microcode/firmware/microcode' with driver \
'(unknown'

If it does not work, than maybe just remove it? They driver, or maybe
the warning.