Vaio eeprom security issue

Jean Delvare khali at
Wed Aug 6 23:36:17 CEST 2003

Hi all,

As some of you may know, I have been working on an EEPROM that is found
in Sony Vaio laptops for quite some time now. I recently found that the
BIOS password, when set, is stored in that EEPROM in a very lightly
coded way (took me less than a minute to find the encoding/decoding
method). Since the eeprom module will export the data to userspace, it
looks like we could have a security issue.

The good thing is that I was precisely using that field as a way to
detect the EEPROM, so once a password is set, sensors-detect won't
detect it anymore (and thus give it a confidence 1 only). Sensors will
not recognize the EEPROM either.

The bad thing is that the data is still exported to userspace. What's
more, this field is also where the regular SPD main data are (the memory
type and size). Fortunately, the values should be different enough so
that no password could make sensors think this is a SPD EEPROM. Still,
some password could make the SPD checksum succeed (while it usually
fails on Sony Vaio EEPROMs) and confuse sensors-detect.

So, here is the proposed plan:

1* Fix sensors-detect so that it will identify the two different kind of
eeproms correctly. I think we could have two distinct entries in our
chips list (say "SPD EEPROM" and "Sony Vaio EEPROM"), even if both are
EEPROMs, using the same driver and prefix.

2* Check that detection procedures in the eeprom driver are correct.
IIRC, there is almost no check unless checksum=1, maybe some checks
should be added.

3* Define a security policy for that password issue. I think we simply
should disable the Vaio EEPROM in the eeprom module if we find there is
a password set. It could be forced using the force_eeprom module
parameter (or should we define another module parameter?) Another
possibility is to hide that particular field instead, but I'm not sure
it's worth the work.

Jean Delvare

More information about the lm-sensors mailing list