Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Kernel doesn't link to it?
Yup - this will finally clear any doubt...
Posted Nov 9, 2010 3:21 UTC (Tue) by gus3 (guest, #61103)
In the sense of affecting the behavior of the CPU, the only difference I see is that object code is external, where microcode is internal to the CPU. You can verify that the object code under the GPL doesn't run counter to your intentions, and you can also improve it or tailor it to your purposes. Why can't you do the same with microcode? It is also executable, just on a different level.
I'm not necessarily arguing for opening up Intel's microcode format (although dang, that would be sweet for my curious mind). I'm simply saying Linus is a bit two-faced for arguing against nVidia's proprietary module, but including Intel's microcode.
Posted Nov 9, 2010 3:48 UTC (Tue) by bojan (subscriber, #14302)
That is one interpretation.
Mine is that because Linus writes Linux (and not Intel microcode) and nVidia drivers are linked into the kernel, the traces of such crashed kernel become next to useless, because nobody can see the source of such linked-in modules (and they could be causing the crash). Ergo, nVidia and others were put on the "tainted" list, so that users don't expect help if they come to Linus with a "tainted" trace.
Sure, if Intel provides dodgy microcode, your machine will be just as screwed. But at least this is not something Linus is supposed to support in any way, shape or form, because it really is outside the kernel.
Posted Nov 9, 2010 6:43 UTC (Tue) by dlang (✭ supporter ✭, #313)
however, in the nvidia driver situation, the code is being loaded into kernel space and can mess with other, seemingly unrelated things (if by no other way thatn by not following all the locking needed to make access to something safe)
Posted Nov 9, 2010 13:47 UTC (Tue) by lxoliva (subscriber, #40702)
As for tainting, I really don't understand why a driver that has access to DMA, system memory, buses and all on the primary CPU taints the kernel, but a blob that runs on a separate CPU and has access to DMA, system memory, buses and all doesn't taint it.
Posted Nov 9, 2010 14:11 UTC (Tue) by hmh (subscriber, #3838)
You'd also need to taint anything that lacks an IOMMU configured in such a way that NO device can access non-exclusive memory, and where a device cannot attack other devices in the same bus.
I.e. it would be useless.
Posted Nov 10, 2010 7:28 UTC (Wed) by Los__D (guest, #15263)
Posted Nov 10, 2010 7:34 UTC (Wed) by dlang (✭ supporter ✭, #313)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds