| 31 | | 2) The sequence of probes in sensors-detect has been changed so that |
|---|
| 32 | | 24RF08 eeproms are not corrupted. This *should* prevent corruption |
|---|
| 33 | | of 24RF08 eeproms in any non-IBM systems in most cases. |
|---|
| | 31 | 2) The probing command (quick write 0) has been replaced by a different |
|---|
| | 32 | command (read byte) for addresses where eeproms are known to live. |
|---|
| | 33 | This should prevent corruption of 24RF08 eeproms in any system, |
|---|
| | 34 | IBM or not. A similar change was made to i2cdetect as well, although |
|---|
| | 35 | no corruption was ever reported using this tool. |
|---|
| 66 | | As described above, our 2.6.5 release "blacklisted" all IBM |
|---|
| 67 | | systems. We were planning to refine refine the system detection so that |
|---|
| 68 | | only those models containing 24RF08's are blacklisted. But it looks like |
|---|
| 69 | | we will not get sufficient cooperation from IBM to implement a reliable |
|---|
| 70 | | blacklist. For this reason, we will now be using the other approach: |
|---|
| 71 | | a "white list" of known-to-be-safe systems. This is the only safe way. |
|---|
| | 68 | As described above, our 2.6.5 release "blacklisted" all IBM systems. |
|---|
| | 69 | For a moment, we have been planning to refine the system detection |
|---|
| | 70 | so that only those models containing 24RF08's are blacklisted. After that, |
|---|
| | 71 | we planned to use a different approach: a "white list" of known-to-be-safe |
|---|
| | 72 | systems. In both cases, it would require continuous updates of a machines |
|---|
| | 73 | list. This would have been slow and inefficient. |
|---|
| 73 | | Systems will be added to the white list at a slow rate, on user report. |
|---|
| 74 | | Basically, users wanting to use lm_sensors on their IBM systems, either |
|---|
| 75 | | because they know for sure that the system doesn't have the 24RF08 chip, |
|---|
| 76 | | or because they like playing with fire, have to bypass the securities we |
|---|
| 77 | | have implemented, and then report (hopefully) success, then we add their |
|---|
| 78 | | system signature to the white list. Note that this list is only |
|---|
| 79 | | implemented in sensors-detect at the moment, not the i2c-piix4 bus |
|---|
| 80 | | driver. |
|---|
| | 75 | The latest idea is to stop using the dangerous command for EEPROM |
|---|
| | 76 | addresses. That way, risks of corruption are reduced to zero. This was |
|---|
| | 77 | already done for user-space tools, as mentioned above. Once this will |
|---|
| | 78 | have been tested and we are sure that there are no drawbacks, we'll |
|---|
| | 79 | do the same on the kernel side in Linux 2.6. The change won't occur in |
|---|
| | 80 | Linux 2.4 however, because it implies changes to both i2c modules and |
|---|
| | 81 | lm_sensors modules. It is possible to use mismatching versions of |
|---|
| | 82 | these modules, and when doing so, the fix would become more dangerous |
|---|
| | 83 | than helpful. |
|---|