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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4910AFC1.2080306@natemccallum.com>
Date:	Tue, 04 Nov 2008 15:25:37 -0500
From:	Nathaniel McCallum <nathaniel@...emccallum.com>
To:	Kay Sievers <kay.sievers@...y.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH] Loaded driver modalias

Kay Sievers wrote:
> On Tue, Nov 4, 2008 at 19:39, Nathaniel McCallum
> <nathaniel@...emccallum.com> wrote:
>   
>> Please CC me to responses as I'm not subscribed to LKML.  Also, this is my
>> first kernel patch, advise is certainly welcome.
>>
>> For something I'm working on I have the need to answer the question, "given
>> a hardware ID, does Linux distro X have a driver to support this hardware?"
>> and more specifically, "which drivers support this hardware?" I can,
>> generally speaking, get this data from files like
>> /lib/modules/*/modules.alias.  However, this does not work for drivers built
>> into the kernel.  With that in mind, I've cooked up a little proof of
>> concept. Basically, its a sysfs file
>> /sys/modules/$module/drivers/$driver/modalias that, when read, contains
>> modalias-style filters for this driver.
>>
>> The attached patch only does this for PCI drivers, each subsystem would need
>> a patch like this.  Is this idea crazy?  Is there a better implementation?
>>     
>
> Hmm, what if that gets larger than 4k? It seems not really like
> something for sysfs. There are also drivers which export a modalias
> which matches more devices, than the device it actually would accept
> to bind to. Some driver have logic in the match() function to exclude
> stuff.
>   
In this current patch, an error is returned.  Like I said, this is more 
proof of concept than anything.  I'm trying to ask a running kernel 
"What hardware do you at least pretend to support?" While I would love 
to get only the drivers that would actually bind to the device, I don't 
suspect this is possible since you'd need real or emulated hardware to 
test this.  One of my explicit design requirements is that the hardware 
ids don't represent "real" hardware.  The hardware might exist in real 
life, but I don't have it (and I can't emulate it).  I just want to know 
what Linux would try to do with the hardware *if* I had it.  Thus, I 
don't really care about the logic in the match() function since it would 
require real hardware.

What method would be appropriate for this other than sysfs?
> What's the exact information you need? Would it be sufficient  to ask
> a bus with a modalias string, which driver of that bus matched that
> device?
>   
I want to create a database of this information that exists outside the 
Linux kernel.  This database should contain a map of filters to drivers 
such that, given any hardware id (real or otherwise), I should be able 
to determine which kernel drivers would attempt to "do something" with 
this hardware.

So, first I would snapshot one or more distributions (and perhaps 
different kernels in the same distro).  Then I would compare hardware 
IDs against this snapshot.  Once this driver database is built, you can 
do lots of things with it, including stuff like regression testing.  The 
important thing is that the hardware id is not available at the time the 
snapshot is taken.

One of the possible usages for this, outside of my project, would be to 
create a list of the most common hardware ids out there.  Then, for each 
kernel release, a snapshot could be taken of its hardware support.  
Then, you could test to make sure that all common hardware is supported 
and that no regressions have appeared.  Sure, this doesn't test whether 
the *real* hardware works or not.  However, testing physical hardware 
cannot be easily automated, and this can.

Nathaniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ