linux-kernel - RFC: kdrvscan

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>] [day] [month] [year] [list]

Message-ID: <AANLkTimQoDOex6_EywOXJdtBZ93b+CVxWfv2QPo1r1WF@mail.gmail.com>
Date:	Thu, 10 Feb 2011 14:17:25 -0500
From:	Nathaniel McCallum <nathaniel@...emccallum.com>
To:	linux-kernel@...r.kernel.org
Subject: RFC: kdrvscan

Please CC me on any responses as I'm not subscribed to lkml.

A while back I posted (https://lkml.org/lkml/2009/10/1/334) a patch to
tag *_device_id tables into sections so that one could easily extract
an inventory a linux kernel binary to determine what hardware it
supports.  Since that time, I have pursued another solution, namely
kdrvscan.  kdrvscan is a small command line program which fingerprints
the symbols listed in System.map.  This program has the advantage of
not requiring any change to the kernel binary.  However, it also
commits the cardinal sin of importing kernel headers into user space.
The source code is attached along with a simple Makefile that works on
my system.  Before I go much further in cleaning it up I'm wondering,
does this approach make sense?  Could a utility like this be included
upstream?

Nathaniel

View attachment "kdrvscan.c" of type "text/x-csrc" (13867 bytes)

Download attachment "Makefile" of type "application/octet-stream" (473 bytes)