linux-kernel - Re: Kubuntu's udev broken with 2.6.18-rc2-mm1

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: <44CCBBC7.3070801@free.fr>
Date:	Sun, 30 Jul 2006 16:01:43 +0200
From:	Laurent Riffard <laurent.riffard@...e.fr>
To:	ajwade@...001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com
CC:	Andrew Morton <akpm@...l.org>, andrew.j.wade@...il.com,
	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>
Subject: Re: Kubuntu's udev broken with 2.6.18-rc2-mm1

Le 28.07.2006 16:33, Andrew James Wade a écrit :
> On Thursday 27 July 2006 16:12, Greg KH wrote:
>> On Thu, Jul 27, 2006 at 12:56:55PM -0700, Andrew Morton wrote:
>>> On Fri, 28 Jul 2006 15:46:08 -0400
>>> Andrew James Wade <andrew.j.wade@...il.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Some change between -rc1-mm2 and -rc2-mm1 broke Kubuntu's udev
>>>> (079-0ubuntu34). In particular /dev/mem went missing, and /dev/null had
>>>> bogus permissions (crw-------). I've kludged around the problem by
>>>> populating /lib/udev/devices from a good /dev, but I'm assuming the
>>>> breakage was unintentional.
>>>>
>>> /dev/null damage is due to a combination of vdso-hash-style-fix.patch and
>>> doing the kernel build as root (don't do that).
>>>
>>> I don't know what happened to /dev/mem.
>> Me either.  Look in /sys/class/mem/  Is it full of symlinks or real
>> directories?
> 
> Symlinks.
> 
>> If symlinks, your version of udev should be able to handle it properly,
>> but might have a bug somehow.
>>
>> Try running udevmonitor and echo a "1" to /sys/class/mem/mem/uevent and
>> see if udev creates the device properly or not.
> 
> udevmonitor prints the received event from the kernel [UEVENT]
> and the event which udev sends out after rule processing [UDEV]
> 
> UEVENT[1154093169.330045] add@...vices/mem
> UDEV  [1154093169.331914] add@...vices/mem
> 
> The device node was not created.
> 
> udev.log for 2.6.18-rc1-mm2 (which does work) has these lines:
> 
> UEVENT[1154105360.092631] add@...ass/mem/mem
> ACTION=add
> DEVPATH=/class/mem/mem
> SUBSYSTEM=mem
> SEQNUM=589
> MAJOR=1
> MINOR=1
> 
> ...
> 
> UDEV  [1154105363.575086] add@...ass/mem/mem
> UDEV_LOG=3
> ACTION=add
> DEVPATH=/class/mem/mem
> SUBSYSTEM=mem
> SEQNUM=589
> MAJOR=1
> MINOR=1
> UDEVD_EVENT=1
> DEVNAME=/dev/mem
> 
> The Changelog for udev v081 has:
> "prepare moving of /sys/class devices to /sys/devices"
> Is this related? 
> 
> Thanks,
> Andrew Wade

gregkh-driver-mem-devices.patch seems to be the culprit.

With this patch, /sys/class/mem/ looks like this:

/sys/class/mem/
|-- full -> ../../devices/full
|-- kmem -> ../../devices/kmem
|-- kmsg -> ../../devices/kmsg
|-- mem -> ../../devices/mem
|-- null -> ../../devices/null
|-- port -> ../../devices/port
|-- random -> ../../devices/random
|-- urandom -> ../../devices/urandom
`-- zero -> ../../devices/zero

9 directories, 0 files

And /sys/class/mem/*/ look like this:

/sys/class/mem/full/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/kmem/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/kmsg/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/mem/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/null/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/port/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/random/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/urandom/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/zero/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent

18 directories, 36 files

In this situation, udev (version 096 here) is unable to create these
device files (/dev/full, /dev/kmem, /dev/kmsg, etc.). /dev/null does
exist (with wrong permissions) because it has been created by the
initrd script.

In order to get back the device files, I have to run the following
command:
# for f in /sys/class/mem/*/uevent; do echo 1 > $f; done

After gregkh-driver-mem-devices.patch been reverted, all is working
fine and /sys/class/mem/ looks like this:

/sys/class/mem/
|-- full
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- kmem
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- kmsg
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- mem
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- null
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- port
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- random
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- urandom
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
`-- zero
    |-- dev
    |-- subsystem -> ../../../class/mem
    `-- uevent

18 directories, 18 files

~~
laurent
-
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/