On 23/03/07, Shaohua Li <[email protected]> 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
"Daniel J Blueman" <[email protected]> writes:
> On 23/03/07, Shaohua Li <[email protected]> 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
Andi Kleen wrote:
> "Daniel J Blueman" <[email protected]> writes:
>
>> On 23/03/07, Shaohua Li <[email protected]> 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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
(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...)
> 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
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...
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?
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
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.
On 28/06/07, Chuck Ebbert <[email protected]> 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
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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
> 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
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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
> 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