linux-kernel - Re: [RFC PATCH 1/2] i2c: Add i2c_verify_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 8 Apr 2018 12:28:53 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     Wolfram Sang <wsa@...-dreams.de>,
        Guenter Roeck <linux@...ck-us.net>
Cc:     linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] i2c: Add i2c_verify_device_id() to verify device
 id

Sorry for replying to self...

On 2018-04-08 11:08, Peter Rosin wrote:
> On 2018-04-08 09:34, Wolfram Sang wrote:
>> Hi,
>>
>> On Mon, Mar 19, 2018 at 09:10:58AM -0700, Guenter Roeck wrote:
>>> Commit dde67eb1beeb ("i2c: add i2c_get_device_id() to get the standard
>>> I2C device id") added a function to return the standard I2C device ID.
>>> Use that function to verify the device ID of a given device.
>>
>> I am very open to these patches, just...
>>
>>>
>>> Cc: Peter Rosin <peda@...ntia.se>
>>> Signed-off-by: Guenter Roeck <linux@...ck-us.net>
>>> ---
>>> RFC:
>>> - Compile tested only
>>
>> ... I would really like to have them tested. After that happened, Peter
>> and I can figure out who should apply them for seamless upstreaming.
>>
>>> - Should there also be I2C_DEVICE_PART_ID_ANY to enable maching
>>>   against all parts from a given manufacturer ?
>>
>> Can't we just add it when we need it?

Is it really reasonable to verify just the manufacturer? I don't see the
use case? I mean, we can never know if the verified manufacturer will
release unexpected chips further down the line.

>>> +		dev_err(&client->dev, "unexpected device id %03x-%03x-%x\n",
>>> +			real_id.manufacturer_id, real_id.part_id,
>>> +			real_id.die_revision);
>>> +		return -ENODEV;
>>
>> I wonder about the ERR loglevel. ENODEV is not an error, I'd think?
> 
> Well, in this case someone has said that I2C addr <xyz> is a <uvw> device,
> but when verifying the actual device at that addr, that's not what is
> found. Hence, I think an error is appropriate? On the other hand, a driver
> that can handle different kinds of devices might not want the error. But
> for that case, maybe the driver should be using i2c_get_device_id() and
> figure out the details by itself?

Maybe it should just be -EINVAL, and that's your real objection?

Cheers,
Peter