linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: LKML <linux-kernel@vger.kernel.org>,
	Linux I2C <linux-i2c@vger.kernel.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: VAIO EEPROM support in at24
Date: Tue, 17 Mar 2020 15:14:09 +0100	[thread overview]
Message-ID: <20200317151409.7940926c@endymion> (raw)

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

             reply	other threads:[~2020-03-17 14:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-17 14:14 Jean Delvare [this message]
2020-03-17 14:32 ` VAIO EEPROM support in at24 Bartosz Golaszewski
2020-03-17 15:01   ` Wolfram Sang
2020-08-03 14:53     ` Jean Delvare
2020-08-05 14:36   ` Jean Delvare
2020-08-05 18:14     ` Bartosz Golaszewski
2020-08-06 12:14       ` Jean Delvare
2020-08-07  9:31     ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200317151409.7940926c@endymion \
    --to=jdelvare@suse.de \
    --cc=arnd@arndb.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).