Recent Features
| |||||||||||||
Yup - this will finally clear any doubt...Yup - this will finally clear any doubt...Posted Nov 9, 2010 0:48 UTC (Tue) by gus3 (guest, #61103)In reply to: Yup - this will finally clear any doubt... by bojan Parent article: FSFLA: Linux kernel is "open core"
As soon as they get corporate permission, or the legal right, to reverse-engineer the devices, the firmware can be disassembled and then modified. And then we can also reverse-engineer nVidia's 3D acceleration.
Wait a minute. Didn't Linus rail against nVidia's using GPL'd API's a few years ago? Rather than outright banning the "nvidia" module, the kernel team added the "tainted" kernel flag, so that kernel crashes could be flagged as "unsupported stuff here".
How is the Intel microcode any different?
(Log in to post comments)
Yup - this will finally clear any doubt... Posted Nov 9, 2010 1:28 UTC (Tue) by bojan (subscriber, #14302) [Link]
> How is the Intel microcode any different?
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) [Link]
In the sense of the kernel object code in core, yes, that's true.
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.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:48 UTC (Tue) by bojan (subscriber, #14302) [Link]
> I'm simply saying Linus is a bit two-faced for arguing against nVidia's proprietary module, but including Intel's microcode.
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.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 6:43 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
you may not be aware that when the kernel loads, it includes microcode that it loads into the CPU. the is just the same as loading firmware into an external device.
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)
Yup - this will finally clear any doubt... Posted Nov 9, 2010 13:47 UTC (Tue) by lxoliva (guest, #40702) [Link]
The microcode is actually not part of the kernel. The kernel supports loading it, but the actual microcode is separate.
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.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 14:11 UTC (Tue) by hmh (subscriber, #3838) [Link]
You'd need to taint anything that is SMM-capable.
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.
Yup - this will finally clear any doubt... Posted Nov 10, 2010 7:28 UTC (Wed) by Los__D (guest, #15263) [Link]
Then I guess you'd taint any device that we don't have complete HDLs for?
Yup - this will finally clear any doubt... Posted Nov 10, 2010 7:34 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
don't forget the requirement for the installation tools for the software, so that would mean that they would not only have to provide you with the HDL for the chips, they would also have to provide you with the ability to produce a modified chip and put it on the board.
|
|||||||||||||