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/
Thanks,
Shaohua
> > 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
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 :)
> > > > 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
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.
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
> 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 <davi...@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
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...)
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
What about deliberate exploits of these bugs from userspace? Theo thinks
they are possible...
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
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.
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
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
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 <davi...@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
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
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
-
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.