2.5.6 lm_sensors]
PATCH 2/9 2.5.6 lm_sensors]
-------------- next part --------------
An embedded message was scrubbed...
From: "Mark Studebaker" <[email protected]>
Subject: Re: [patch 2/9] 2.5.6 lm_sensors
Date: Fri, 19 Jul 2002 22:06:20 -0400
Size: 2854
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20020720/dbf3d0b9/attachment.mht
PATCH 2/9 2.5.6 lm_sensors]
Yeah, I can see both sides to this. Unfortunately, the only serious issue we had is with those (apparently) few old Thinkpads. Even Keith of IBM (who has been let go after IBM dropped Linux support for Thinkpads) couldn't get many details on it. He thought it was a Flash ROM on the PIIX4 I2C bus which responded in a non-standard way to being probed (I'm calling the I2C protocol for eeproms 'standard').
I did some quick checking, and the list of known susceptible Thinkpads don't seem to be sold any more. So it might be only an issue for someone with old hardware.
I guess we can put it like this:
The I2C bus drivers are safe. Most use PCI access to identify and configure the bus masters. Pretty reliable and safe.
Chip drivers are less safe given the nature of not knowing what are on the busses. They use a combination of addressing space division, and probing of 'signature' registers (which might be chip ID or manufacturer registers) to confirm the indentity of the chip. Still, no reports of corruption or horrible things happening with installing all the chip drivers on a system. But, we can't do 'ideal' detection... it's still possible a device exists (or will exists) which one of our drivers will mangle.
Least safe are user-space apps which do scanning by reading and/or writing indescriminately to all the addresses on all busses. We provide a lot of warnings for the only known group of users who may be susceptible to a corruption issue in this case.
Alan worries that a new machine might come out (or stuff might exist that we don't know about) with a device which gets corrupted from a standard kernel driver. That would suck! It may be unlikely, but it would suck.
Phil
Quoted 46 lines · Mark D. Studebaker
X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to [email protected] using -f
Subject: Re: [patch 2/9] 2.5.6lm_sensors
From: Alan Cox <[email protected]>
To: Mark Studebaker <[email protected]>
Cc: Linus Torvalds <[email protected]>,
Albert Cranford<[email protected]>In-Reply-To: <[email protected]>
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6)
Date: 20 Jul 2002 21:07:50 +0100Quoted 4 lines · Mark Studebaker
It's our userspace detection script, "sensors-detect", that causes the problems, and we do not have any info from IBM that would allow us to fix it.
The script has a big fat warning at the beginning.So the answer is no.
Quoted 2 lines
We don't know if it is the script itself, or certain modules it loads, that cause the problem.
And its not only no its "no and we are not sure what is going on or if what we have now is always safe".
Quoted 4 lines
Red Hat has been shipping kernels with our modules for over a year, IIRC. We do not have a single report of an IBM Thinkpad user loading a module and
getting fubared.The user has to choose to enable it and that is quite tricky. I am still deeply opposed to Red Hat shipping this code. You don't even seem to use the DMI data to identify what kind of SM management is present.
Quoted 5 lines
My own theory is that the Thinkpads have some non-standard Serial Presence Detect eeproms for their memory, that those are being corrupted by the sensors-detect script,
which prevents the BIOS from correctly discovering the SDRAMs and booting. Just a theory though.So anybody else could be using the same chips and we might not know yet ?
Alan
Signature · 3 lines
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR [email protected] -- http://www.netroedge.com/~phil PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. StudebakerYup. If we can't get more details, then I suggest we detect for the presence of a Thinkpad and not allow i2c-piix4 to initialize. According to Keith's old email, that would be sufficient to prevent any possible communication with the compromisable Flash ROM.
When we were emailing with Keith, I think he said that the technical details for detecting Thinkpads was company-confidential but he was working to make it available to us. Never heard any more on that... The linux.kernel newsgroup suggested adding an explicit kernel config that said 'Support for Thinkpads? [Y/n]'. Another person suggested that it be more preciously worded as 'Destroy my precious Thinkpad? [Y/n]'.... ;')
We could also look to see if there is any existing code in the Kernel (or elsewhere) which detects for Thinkpads.
Phil
Quoted 99 lines · Mark D. Studebaker
Well, Alan Has Spoken.
Unless we identify and fix the problem, we won't be in the kernel. We'll either have to get through to somebody at IBM (perhaps we can find Keith wherever he is now for help?) or else buy an old Thinkpad and reverse engineer it.
I can't even think of a reply to Alan worth sending. Any suggestions?Quoted 90 lines · [email protected] wrote:
Yeah, I can see both sides to this. Unfortunately, the only serious issue we had is with those (apparently) few old Thinkpads. Even Keith of IBM (who has been let go after IBM dropped Linux support for Thinkpads) couldn't get many details on it. He thought it was a Flash ROM on the PIIX4 I2C bus which responded in a non-standard way to being probed (I'm calling the I2C protocol for eeproms 'standard').
I did some quick checking, and the list of known susceptible Thinkpads don't seem to be sold any more. So it might be only an issue for someone with old hardware.
I guess we can put it like this:
The I2C bus drivers are safe. Most use PCI access to identify and configure the bus masters. Pretty reliable and safe.
Chip drivers are less safe given the nature of not knowing what are on the busses. They use a combination of addressing space division, and probing of 'signature' registers (which might be chip ID or manufacturer registers) to confirm the indentity of the chip. Still, no reports of corruption or horrible things happening with installing all the chip drivers on a system. But, we can't do 'ideal' detection... it's still possible a device exists (or will exists) which one of our drivers will mangle.
Least safe are user-space apps which do scanning by reading and/or writing indescriminately to all the addresses on all busses. We provide a lot of warnings for the only known group of users who may be susceptible to a corruption issue in this case.
Alan worries that a new machine might come out (or stuff might exist that we don't know about) with a device which gets corrupted from a standard kernel driver. That would suck! It may be unlikely, but it would suck.
Phil
Quoted 41 lines · Mark D. Studebaker
X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to [email protected] using -f
Subject: Re: [patch 2/9] 2.5.6lm_sensors
From: Alan Cox <[email protected]>
To: Mark Studebaker <[email protected]>
Cc: Linus Torvalds <[email protected]>,
Albert Cranford<[email protected]>In-Reply-To: <[email protected]>
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6)
Date: 20 Jul 2002 21:07:50 +0100Quoted 4 lines · Mark Studebaker
It's our userspace detection script, "sensors-detect", that causes the problems, and we do not have any info from IBM that would allow us to fix it.
The script has a big fat warning at the beginning.So the answer is no.
Quoted 2 lines
We don't know if it is the script itself, or certain modules it loads, that cause the problem.
And its not only no its "no and we are not sure what is going on or if what we have now is always safe".
Quoted 4 lines
Red Hat has been shipping kernels with our modules for over a year, IIRC. We do not have a single report of an IBM Thinkpad user loading a module and
getting fubared.The user has to choose to enable it and that is quite tricky. I am still deeply opposed to Red Hat shipping this code. You don't even seem to use the DMI data to identify what kind of SM management is present.
Quoted 5 lines
My own theory is that the Thinkpads have some non-standard Serial Presence Detect eeproms for their memory, that those are being corrupted by the sensors-detect script,
which prevents the BIOS from correctly discovering the SDRAMs and booting. Just a theory though.Quoted 5 lines
So anybody else could be using the same chips and we might not know yet ?
Alan
--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[email protected] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
Signature · 3 lines
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR [email protected] -- http://www.netroedge.com/~phil PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. StudebakerIncidently, in the kernel drivers/sound/cs46xx.c, it checks for a 600E and 600X series Thinkpads by checking for the existance of some specific PCI devices. Parhaps it's just as easy as looking for one of a series of specific PCI devices to detect for a Thinkpad?
On linux-thinkpad.org they list the vulnerable Thinkpads as:
ThinkPad 770X
ThinkPad 600E
ThinkPad 770Z
ThinkPad 600X
ThinkPad 240
ThinkPad X20
ThinkPad 570E
It would be nice if we could detect for any Thinkpad, but we might be OK if we just were able to detect the above?
Here's a list of know PCI ID's, which might be useful:
http://pciids.sourceforge.net/pci.db
The names here don't quite match with the scheme above, though...
Phil
Quoted 19 lines · On Sat, Jul 20, 2002 at 03:08:24PM -0700, [email protected] wrote:
Yup. If we can't get more details, then I suggest we detect for the presence of a Thinkpad and not allow i2c-piix4 to initialize. According to Keith's old email, that would be sufficient to prevent any possible communication with the compromisable Flash ROM.
When we were emailing with Keith, I think he said that the technical details for detecting Thinkpads was company-confidential but he was working to make it available to us. Never heard any more on that... The linux.kernel newsgroup suggested adding an explicit kernel config that said 'Support for Thinkpads? [Y/n]'. Another person suggested that it be more preciously worded as 'Destroy my precious Thinkpad? [Y/n]'.... ;')
We could also look to see if there is any existing code in the Kernel (or elsewhere) which detects for Thinkpads.
Phil
Signature · 3 lines
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR [email protected] -- http://www.netroedge.com/~phil PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. StudebakerI guess our canidate solutions are solidifying:
- Detect Thinkpads and disable at least partial functionality (like i2c-piix4 or addresses on all busses from 0x58-0x5F)
- Detect the AT24RF08 and either drive it properly, or safely note and ignore it.
Does this sound right?
Alan's suggestion of detecting a possible vulnerable platform and safely disabling a driver (or the entire i2c/lm-sensors package) with DMI is a safe workaround for this specific issue, but ideally, if we can sense this chip and safely drive it, it would be awesome. That would address Alan's fears of a future machine for which we didn't blacklist having this chip. Perhaps easier said than done, ey?
Anyways, if we do the DMI route, I would detect for brand 'IBM' and blacklist them all. Accesses from 0x58-0x5F anyway (or what ever the range was for this chip).
Not sure how to use DMI? There are some references to DMI in some drivers. The most obvious is drivers/char/i8k.c, but he just copied-and-pasted Alan's code... not ideal usage.
Phil
Quoted 66 lines · Mark D. Studebaker
Do we know for sure that each of the thinkpads listed below has a piix4? Probably not...
Alan implied we should be using DMI data.
I found the attached program by him on the net for dumping out the DMI data. Compile and run as root to see what info is available. Perhaps we could check that for 'thinkpad'. Not clear to me which field would tell us
'what kind of SM management is present' or
what we would do with that info.
Anybody?Quoted 52 lines · [email protected] wrote:
Incidently, in the kernel
drivers/sound/cs46xx.c, it checks for a 600E and 600X series Thinkpads by checking for the existance of some specific PCI devices. Parhaps it's just as easy as looking for one of a series of specific PCI devices to detect for a Thinkpad?On linux-thinkpad.org they list the vulnerable Thinkpads as:
ThinkPad 770X
ThinkPad 600E
ThinkPad 770Z
ThinkPad 600X
ThinkPad 240
ThinkPad X20
ThinkPad 570EIt would be nice if we could detect for any Thinkpad, but we might be OK if we just were able to detect the above?
Here's a list of know PCI ID's, which might be useful:
http://pciids.sourceforge.net/pci.db
The names here don't quite match with the scheme above, though...
Phil
Quoted 14 lines · On Sat, Jul 20, 2002 at 03:08:24PM -0700, [email protected] wrote:
Yup. If we can't get more details, then I suggest we detect for the presence of a Thinkpad and not allow i2c-piix4 to initialize. According to Keith's old email, that would be sufficient to prevent any possible communication with the compromisable Flash ROM.
When we were emailing with Keith, I think he said that the technical details for detecting Thinkpads was company-confidential but he was working to make it available to us. Never heard any more on that... The linux.kernel newsgroup suggested adding an explicit kernel config that said 'Support for Thinkpads? [Y/n]'. Another person suggested that it be more preciously worded as 'Destroy my precious Thinkpad? [Y/n]'.... ;')
Quoted 5 lines
We could also look to see if there is any existing code in the Kernel (or elsewhere) which detects for Thinkpads.
Phil
--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[email protected] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
Signature · 3 lines
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR [email protected] -- http://www.netroedge.com/~phil PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. StudebakerQuoted 5 lines
Red Hat has been shipping kernels with our modules for over a year, IIRC. We do not have a single report of an IBM Thinkpad user loading a
module and getting fubared.
FYI, SuSE is also shipping the sensors modules, as seen on this page:
http://www.suse.de/en/products/suse_linux/i386/packages_personal/sensors.html
Signature · 2 lines
Jean "Khali" Delvare http://www.ensicaen.ismra.fr/~delvare/
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. Studebaker-------------- next part --------------
An embedded message was scrubbed...
From: Alan Cox <[email protected]>
Subject: Re: [patch 2/9] 2.5.6 lm_sensors
Date: 20 Jul 2002 21:07:50 +0100
Size: 2805
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20020720/3aa6681a/attachment.mht
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. StudebakerWell, Alan Has Spoken.
Unless we identify and fix the problem, we won't be in the kernel. We'll either have to get through to somebody at IBM (perhaps we can find Keith wherever he is now for help?) or else buy an old Thinkpad and reverse engineer it.
I can't even think of a reply to Alan worth sending. Any suggestions?
Quoted 90 lines · [email protected] wrote:
Yeah, I can see both sides to this. Unfortunately, the only serious issue we had is with those (apparently) few old Thinkpads. Even Keith of IBM (who has been let go after IBM dropped Linux support for Thinkpads) couldn't get many details on it. He thought it was a Flash ROM on the PIIX4 I2C bus which responded in a non-standard way to being probed (I'm calling the I2C protocol for eeproms 'standard').
I did some quick checking, and the list of known susceptible Thinkpads don't seem to be sold any more. So it might be only an issue for someone with old hardware.
I guess we can put it like this:
The I2C bus drivers are safe. Most use PCI access to identify and configure the bus masters. Pretty reliable and safe.
Chip drivers are less safe given the nature of not knowing what are on the busses. They use a combination of addressing space division, and probing of 'signature' registers (which might be chip ID or manufacturer registers) to confirm the indentity of the chip. Still, no reports of corruption or horrible things happening with installing all the chip drivers on a system. But, we can't do 'ideal' detection... it's still possible a device exists (or will exists) which one of our drivers will mangle.
Least safe are user-space apps which do scanning by reading and/or writing indescriminately to all the addresses on all busses. We provide a lot of warnings for the only known group of users who may be susceptible to a corruption issue in this case.
Alan worries that a new machine might come out (or stuff might exist that we don't know about) with a device which gets corrupted from a standard kernel driver. That would suck! It may be unlikely, but it would suck.
Phil
Quoted 41 lines · Mark D. Studebaker
X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to [email protected] using -f
Subject: Re: [patch 2/9] 2.5.6lm_sensors
From: Alan Cox <[email protected]>
To: Mark Studebaker <[email protected]>
Cc: Linus Torvalds <[email protected]>,
Albert Cranford<[email protected]>In-Reply-To: <[email protected]>
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6)
Date: 20 Jul 2002 21:07:50 +0100Quoted 4 lines · Mark Studebaker
It's our userspace detection script, "sensors-detect", that causes the problems, and we do not have any info from IBM that would allow us to fix it.
The script has a big fat warning at the beginning.So the answer is no.
Quoted 2 lines
We don't know if it is the script itself, or certain modules it loads, that cause the problem.
And its not only no its "no and we are not sure what is going on or if what we have now is always safe".
Quoted 4 lines
Red Hat has been shipping kernels with our modules for over a year, IIRC. We do not have a single report of an IBM Thinkpad user loading a module and
getting fubared.The user has to choose to enable it and that is quite tricky. I am still deeply opposed to Red Hat shipping this code. You don't even seem to use the DMI data to identify what kind of SM management is present.
Quoted 5 lines
My own theory is that the Thinkpads have some non-standard Serial Presence Detect eeproms for their memory, that those are being corrupted by the sensors-detect script,
which prevents the BIOS from correctly discovering the SDRAMs and booting. Just a theory though.Quoted 5 lines
So anybody else could be using the same chips and we might not know yet ?
Alan
--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[email protected] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. StudebakerDo we know for sure that each of the thinkpads listed below has a piix4? Probably not...
Alan implied we should be using DMI data.
I found the attached program by him on the net for dumping out the DMI data. Compile and run as root to see what info is available. Perhaps we could check that for 'thinkpad'. Not clear to me which field would tell us
'what kind of SM management is present' or
what we would do with that info.
Anybody?
Quoted 46 lines · [email protected] wrote:
Incidently, in the kernel
drivers/sound/cs46xx.c, it checks for a 600E and 600X series Thinkpads by checking for the existance of some specific PCI devices. Parhaps it's just as easy as looking for one of a series of specific PCI devices to detect for a Thinkpad?On linux-thinkpad.org they list the vulnerable Thinkpads as:
ThinkPad 770X
ThinkPad 600E
ThinkPad 770Z
ThinkPad 600X
ThinkPad 240
ThinkPad X20
ThinkPad 570EIt would be nice if we could detect for any Thinkpad, but we might be OK if we just were able to detect the above?
Here's a list of know PCI ID's, which might be useful:
http://pciids.sourceforge.net/pci.db
The names here don't quite match with the scheme above, though...
Phil
Quoted 18 lines · On Sat, Jul 20, 2002 at 03:08:24PM -0700, [email protected] wrote:
Yup. If we can't get more details, then I suggest we detect for the presence of a Thinkpad and not allow i2c-piix4 to initialize. According to Keith's old email, that would be sufficient to prevent any possible communication with the compromisable Flash ROM.
When we were emailing with Keith, I think he said that the technical details for detecting Thinkpads was company-confidential but he was working to make it available to us. Never heard any more on that... The linux.kernel newsgroup suggested adding an explicit kernel config that said 'Support for Thinkpads? [Y/n]'. Another person suggested that it be more preciously worded as 'Destroy my precious Thinkpad? [Y/n]'.... ;')
We could also look to see if there is any existing code in the Kernel (or elsewhere) which detects for Thinkpads.
Quoted 6 lines
Quoted 1 line
Phil
--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[email protected] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmidecode.c.bz2
Type: application/octet-stream
Size: 4931 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20020721/2a00f928/dmidecode.c.obj
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. StudebakerThat's a great find.
(at line 5250).
Also note that at line 3158, it checks for PIIX4, and if not there, the comment says definitely not a Thinkpad.
I'll put the 3 ID's from line 5250 into piix4 as a 'blacklist'. Can somebody do the same in sensors-detect?
(check for those 3 ID's, if one is present, exit with a message).
We may need an lspci -n output from every thinkpad on the planet. Or maybe just reject any board that has any IBM device at all?
Quoted 52 lines · [email protected] wrote:
Incidently, in the kernel
drivers/sound/cs46xx.c, it checks for a 600E and 600X series Thinkpads by checking for the existance of some specific PCI devices. Parhaps it's just as easy as looking for one of a series of specific PCI devices to detect for a Thinkpad?On linux-thinkpad.org they list the vulnerable Thinkpads as:
ThinkPad 770X
ThinkPad 600E
ThinkPad 770Z
ThinkPad 600X
ThinkPad 240
ThinkPad X20
ThinkPad 570EIt would be nice if we could detect for any Thinkpad, but we might be OK if we just were able to detect the above?
Here's a list of know PCI ID's, which might be useful:
http://pciids.sourceforge.net/pci.db
The names here don't quite match with the scheme above, though...
Phil
Quoted 14 lines · On Sat, Jul 20, 2002 at 03:08:24PM -0700, [email protected] wrote:
Yup. If we can't get more details, then I suggest we detect for the presence of a Thinkpad and not allow i2c-piix4 to initialize. According to Keith's old email, that would be sufficient to prevent any possible communication with the compromisable Flash ROM.
When we were emailing with Keith, I think he said that the technical details for detecting Thinkpads was company-confidential but he was working to make it available to us. Never heard any more on that... The linux.kernel newsgroup suggested adding an explicit kernel config that said 'Support for Thinkpads? [Y/n]'. Another person suggested that it be more preciously worded as 'Destroy my precious Thinkpad? [Y/n]'.... ;')
Quoted 5 lines
We could also look to see if there is any existing code in the Kernel (or elsewhere) which detects for Thinkpads.
Phil
--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[email protected] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. Studebaker-------------- next part --------------
An embedded message was scrubbed...
From: "Mark D. Studebaker" <[email protected]>
Subject: Re: [patch 2/9] 2.5.6 lm_sensors
Date: Sun, 21 Jul 2002 17:21:46 -0400
Size: 2862
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20020721/1a909647/attachment.mht
PATCH 2/9 2.5.6 lm_sensors]
In reply to Mark D. StudebakerAgreed.
My preference is only i2c-piix4 and sensors-detect; and my preference is using PCI ID's and not DMI. But we may have to use DMI to be safe.
On the 24RF08 itself, our response will depend on whether the corruption is via addresses 0x54-0x57, or via 0x5C.
I ordered samples today. When I get them I'll ask who else wants one to test with.
Depending on the test results we may have to do something to eeprom.c as well.
Quoted 100 lines · [email protected] wrote:
I guess our canidate solutions are solidifying:
- Detect Thinkpads and disable at least partial functionality (like i2c-piix4 or addresses on all busses from 0x58-0x5F)
- Detect the AT24RF08 and either drive it properly, or safely note and ignore it.
Does this sound right?
Alan's suggestion of detecting a possible vulnerable platform and safely disabling a driver (or the entire i2c/lm-sensors package) with DMI is a safe workaround for this specific issue, but ideally, if we can sense this chip and safely drive it, it would be awesome. That would address Alan's fears of a future machine for which we didn't blacklist having this chip. Perhaps easier said than done, ey?
Anyways, if we do the DMI route, I would detect for brand 'IBM' and blacklist them all. Accesses from 0x58-0x5F anyway (or what ever the range was for this chip).
Not sure how to use DMI? There are some references to DMI in some drivers. The most obvious is
drivers/char/i8k.c, but he just copied-and-pasted Alan's code... not ideal usage.Phil
Quoted 13 lines · Mark D. Studebaker
Do we know for sure that each of the thinkpads listed below has a piix4? Probably not...
Alan implied we should be using DMI data.
I found the attached program by him on the net for dumping out the DMI data. Compile and run as root to see what info is available. Perhaps we could check that for 'thinkpad'. Not clear to me which field would tell us
'what kind of SM management is present' or
what we would do with that info.
Anybody?Quoted 53 lines
Quoted 52 lines · [email protected] wrote:
Incidently, in the kernel
drivers/sound/cs46xx.c, it checks for a 600E and 600X series Thinkpads by checking for the existance of some specific PCI devices. Parhaps it's just as easy as looking for one of a series of specific PCI devices to detect for a Thinkpad?On linux-thinkpad.org they list the vulnerable Thinkpads as:
ThinkPad 770X
ThinkPad 600E
ThinkPad 770Z
ThinkPad 600X
ThinkPad 240
ThinkPad X20
ThinkPad 570EIt would be nice if we could detect for any Thinkpad, but we might be OK if we just were able to detect the above?
Here's a list of know PCI ID's, which might be useful:
http://pciids.sourceforge.net/pci.db
The names here don't quite match with the scheme above, though...
Phil
Quoted 14 lines · On Sat, Jul 20, 2002 at 03:08:24PM -0700, [email protected] wrote:
Yup. If we can't get more details, then I suggest we detect for the presence of a Thinkpad and not allow i2c-piix4 to initialize. According to Keith's old email, that would be sufficient to prevent any possible communication with the compromisable Flash ROM.
When we were emailing with Keith, I think he said that the technical details for detecting Thinkpads was company-confidential but he was working to make it available to us. Never heard any more on that... The linux.kernel newsgroup suggested adding an explicit kernel config that said 'Support for Thinkpads? [Y/n]'. Another person suggested that it be more preciously worded as 'Destroy my precious Thinkpad? [Y/n]'.... ;')
Quoted 5 lines
We could also look to see if there is any existing code in the Kernel (or elsewhere) which detects for Thinkpads.
Phil
--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[email protected] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[email protected] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A