[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200317151409.7940926c@endymion>
Date: Tue, 17 Mar 2020 15:14:09 +0100
From: Jean Delvare <jdelvare@...e.de>
To: LKML <linux-kernel@...r.kernel.org>,
Linux I2C <linux-i2c@...r.kernel.org>
Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: VAIO EEPROM support in at24
Hi all,
As the legacy eeprom driver is being phased out, I am reviewing all its
use cases to ensure that the at24 driver will be a suitable replacement.
One issue I have found is the handling of specific EEPROMs found on the
SMBus of some Sony VAIO laptops. The legacy eeprom driver would expose
them to user-space, read-only for all users. It would also recognize
them as VAIO EEPROMs and would hide some bytes from non-root users
because these bytes contain the BIOS password in a lightly encoded form.
In order to keep the same level of functionality, we would have to offer
the same with the at24 driver. At this time, the user has to
instantiate a "24c02" device manually from user-space. By default this
device has permissions 600, which is insufficient for users, and
dangerous for root, so a quick chmod 444 is needed.
Without the password issue, I would just document the procedure and
live with it. However in order to protect the password from being read
by random users, the driver itself needs to know that it is dealing
with a specific type of EEPROM. It seems that we need to introduce a
new device flavor to the at24 driver for this purpose.
I see that we already have a number of specific flags (AT24_FLAG_SERIAL
and AT24_FLAG_MAC) so I suppose we could add something similar for
these VAIO EEPROMs. Something like:
/* Some Sony VAIO laptops have a 24c02 at 0x57 with product info */
AT24_CHIP_DATA(at24_data_sony_vaio, 2048 / 8,
AT24_FLAG_READONLY | AT24_FLAG_IRUGO | AT24_FLAG_SONY_VAIO);
Then I suppose it's only a matter of conditionally zeroing a selected
range in at24_read() before it returns, to hide the password from
non-root users.
Before I start implementing the idea above, I would like to know if
anyone objects to it, or has a better idea?
Thanks,
--
Jean Delvare
SUSE L3 Support
Powered by blists - more mailing lists