linux-kernel - Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

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: <33435.81.207.0.53.1183993390.squirrel@secure.samage.net>
Date:	Mon, 9 Jul 2007 17:03:10 +0200 (CEST)
From:	"Indan Zupancic" <indan@....nu>
To:	"mikie" <mikie.pl@...il.com>
Cc:	"Kay Sievers" <kay.sievers@...y.org>,
	"Duncan Sands" <duncan.sands@...h.u-psud.fr>,
	linux-kernel@...r.kernel.org
Subject: Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

On Mon, July 9, 2007 16:40, mikie wrote:
> 2007/7/9, Kay Sievers <kay.sievers@...y.org>:
>> On 7/9/07, mikie <mikie.pl@...il.com> wrote:
>> > 2007/7/9, Indan Zupancic <indan@....nu>:
>> > > On Mon, July 9, 2007 10:49, mikie wrote:
>> > > > 2007/7/6, Indan Zupancic <indan@....nu>:
>> > > >> On Fri, July 6, 2007 16:20, Duncan Sands wrote:
>> > > >> > On Friday 6 July 2007 14:54:18 mikie wrote:
>> > > >> >> Hi,
>> > > >> >>
>> > > >> >> I experience some problems with the speedtch.c module, especially in
>> > > >> >> regards to its firmware loader.
>> > > >> >> I am not quite sure if this module is going to load the firmware
>> > > >> >> itself or does it use some external software to do that ?
>> > > >> >
>> > > >> > It loads it itself, using some external software!
>> > > >>
>> > > >> For information, it generates a hotplug event and the kernel calls the
>> > > >> program written at /proc/sys/kernel/hotplug with certain information.
>> > > >> That used to be /sbin/hotplug, became later udev, but today in general
>> > > >> udev reads the uevents generated by the kernel.
>> > > >
>> > > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug.
>> > > > I copied your script to /sbin/hotplug and also added simple logging,
>> > > > so I can see whenever the script is being started. It turns out that
>> > > > the script is not started at all by the kernel...
>> > > >
>> > > > I am afraid that the kernel generates uevents only, could this be true?
>> > >
>> > > Not really, it would break backward compatibility, and if it were true,
>> > > they're remove the /proc/sys/kernel/hotplug setting too. As far as I know,
>> > > if it's set, that program will be executed, and if zero is written to it, only
>> > > uevents are generated.
>> > >
>> > > Make sure that the script is executable (chmod +x)
>> >
>> > Yes I have set it to be executable:
>> > root@srv:/sbin# ls -lah hotplug
>> > -rwxr-xr-x    1 root     root          934 Jul  9 09:13 hotplug
>> >
>> > > and has "#!/bin/sh"
>> > > at the top, or else it won't work. If that's already the case, I've no idea.
>> >
>> > root@srv:/sbin# head hotplug
>> > #!/bin/sh
>> > set -e
>> >
>> >
>> > Everything looks OK, but still it does not fire up the script...
>>
>> It should run, if the kernel creates events. Can you run "udevmonitor
>> --env" while loading the driver? That way we can see if events are
>> generated by the kernel (if you don't have it, no need to install
>> udev, just download the udev tarball, type "make" and run
>> "./udevmonitor --env").
>
> It seems that uevents are generated:

What if you run a very simple script like

#!/bin/sh
echo "test" >> /tmp/test

is it called at all?

If it is then it's probably something with the other script. Try removing
the set -e and/or run it manually with the right parameters set and see if
anything goes wrong. Or use a minimal udev and let it do the hotplugging,
having only rules for speedtouch and firmware loading (attached, but
make sure the paths and pppd call is correct for your system). /dev can stay
static, just change udev.conf to handle /udev or something.

Regards,

Indan

Download attachment "speedtch.rules" of type "application/octet-stream" (287 bytes)