New format Intel microcode...

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

Re: New format Intel microcode...

[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

Re: New format Intel microcode...

[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

Re: New format Intel microcode...

[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 :)

Re: New format Intel microcode...

[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

Re: New format Intel microcode...

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

Re: New format Intel microcode...

[Daniel J Blueman]

On 23/03/07, Shaohua Li <shaohua.li@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

Re: New format Intel microcode...

[Andi Kleen]

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

> On 23/03/07, Shaohua Li <shaohua.li@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

Re: New format Intel microcode...

[Bill Davidsen]

Andi Kleen wrote:
> "Daniel J Blueman" <daniel.blueman@gmail.com> writes:
> 
>> On 23/03/07, Shaohua Li <shaohua.li@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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: New format Intel microcode...

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

Re: New format Intel microcode...

[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?

Re: New format Intel microcode...

[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

Re: New format Intel microcode...

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

Re: New format Intel microcode...

[Daniel J Blueman]

On 28/06/07, Chuck Ebbert <cebbert@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

Re: New format Intel microcode...

[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

Re: New format Intel microcode...

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

Re: New format Intel microcode...

[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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: New format Intel microcode...

[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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: New format Intel microcode...

[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

Re: New format Intel microcode...

[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

Re: New format Intel microcode...

[Alex Riesen]

On 3/23/07, Shaohua Li <shaohua.li@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?

Re: New format Intel microcode...

[Arjan van de Ven]

On Mon, 2007-07-02 at 10:56 +0200, Alex Riesen wrote:
> On 3/23/07, Shaohua Li <shaohua.li@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

Re: New format Intel microcode...

[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 <shaohua.li@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.