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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ