linux-kernel - Re: [RFC] driver core: add a dbg printk for successful probes

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20241030143045.24965-1-laura.nao@collabora.com>
Date: Wed, 30 Oct 2024 15:30:45 +0100
From: Laura Nao <laura.nao@...labora.com>
To: laura.nao@...labora.com,
	dan.carpenter@...aro.org
Cc: anders.roxell@...aro.org,
	ben.copeland@...aro.org,
	gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org,
	naresh.kamboju@...aro.org,
	nfraprado@...labora.com,
	rafael@...nel.org
Subject: Re: [RFC] driver core: add a dbg printk for successful probes

Hi all,

On 10/25/24 14:58, Laura Nao wrote:
> The main challenge with these tests is building a list of devices expected
> to be probed on a given platform, rather than knowing if a certain driver
> was probed. From our experience with KernelCI and bootrr[1], manually
> creating and maintaining such lists can become a high-maintenance task.
> Relying on kernel output with the suggested debug prints as a reference
> file would still require significant upkeep - generating, storing, and
> updating the reference for each platform over time. Additionally, there's a
> risk that some failures could go undetected, if for example a driver is
> missing from the kernel config at the time the reference is created or
> updated.
> 

Building on this, what do you think about adding a sysfs attribute to
identify devices that aren’t meant to be probed by a driver?
I can think of a few cases, like class devices or devices not assigned to a
subsystem, but there are likely many more.

A recent example I encountered is with I2C adapters: while the device for 
the I2C controller itself is expected to bind to a driver, the devices 
created for each I2C bus segment are managed by the same driver but 
don’t have a driver symlink in sysfs. From userspace, looking at all 
devices in sysfs, it’s difficult to tell which ones represent actual 
hardware and which are software abstractions managed by the same driver 
but not directly probed. Having a specific sysfs attribute for these 
cases would make it much easier to tell them apart.  

Any thoughts on this?

Best,

Laura