Re: New format Intel microcode...
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 <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-03-22 at 23:45 +, 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
On Mon, 2007-07-02 at 10:56 +0200, Alex Riesen wrote: > On 3/23/07, Shaohua Li <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-03-22 at 23:45 +, 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
On 3/23/07, Shaohua Li <[EMAIL PROTECTED]> wrote: On Thu, 2007-03-22 at 23:45 +, 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
On 3/23/07, Shaohua Li [EMAIL PROTECTED] wrote: On Thu, 2007-03-22 at 23:45 +, 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
On Mon, 2007-07-02 at 10:56 +0200, Alex Riesen wrote: On 3/23/07, Shaohua Li [EMAIL PROTECTED] wrote: On Thu, 2007-03-22 at 23:45 +, 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 [EMAIL PROTECTED] wrote: On Thu, 2007-03-22 at 23:45 +, 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
(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...) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 +, 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 +, 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
(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...) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
"Daniel J Blueman" <[EMAIL PROTECTED]> writes: > On 23/03/07, Shaohua Li <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-03-22 at 23:45 +, 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
On 23/03/07, Shaohua Li <[EMAIL PROTECTED]> wrote: On Thu, 2007-03-22 at 23:45 +, 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
On 23/03/07, Shaohua Li [EMAIL PROTECTED] wrote: On Thu, 2007-03-22 at 23:45 +, 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
Daniel J Blueman [EMAIL PROTECTED] writes: On 23/03/07, Shaohua Li [EMAIL PROTECTED] wrote: On Thu, 2007-03-22 at 23:45 +, 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
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 :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
On Thu, 2007-03-22 at 23:45 +, 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New format Intel microcode...
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New format Intel microcode...
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New format Intel microcode...
On Thu, 2007-03-22 at 23:45 +, 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
