linux-kernel - Re: Runaway loop with the current git.

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]

Date:	Sun, 7 Dec 2008 18:39:48 +0100
From:	"Kay Sievers" <kay.sievers@...y.org>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	"Evgeniy Polyakov" <zbr@...emap.net>,
	"Herbert Xu" <herbert@...dor.apana.org.au>,
	linux-kernel@...r.kernel.org,
	"Linux Crypto Mailing List" <linux-crypto@...r.kernel.org>
Subject: Re: Runaway loop with the current git.

On Sun, Dec 7, 2008 at 18:28, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> > /dev/console is a logical mapping to a device which may well be
>> > different, loaded after PCI is initialised and dependant on PCI.
>>
>> So wrong. If no driver is associated, like early, in that case, we
>> must return -ENODEV, instead of calling modprobe in a loop. It's a
>> built-in device, and it's easy to fix.
>
> You've clearly no idea how initrd even works have you ?

Not sure, if you understand the real problem. A kernel forked binary
is allowed to access /dev/console, but it triggers a kernel bug.

> If it just
> returned -ENODEV you wouldn't be able to open the console and you
> wouldn't trigger the loading of the module to get the console running. So
> you've now completely buggered the boot process.

Utter nonsense. Exactly when the driver is available shortly later,
the console will work. If it's not backed by a driver, it should not
try to load it, it will never get any driver loaded by opening it. The
kernel must handle that.

> The correct sequence is
>
>        Open device
>                Kernel issues hotplug message
>                        Hotplug script loads drivers to policy

Nonsense. The kernel calls /sbin/modprobe directly, no hotplug involved.

> The problem case you have due to initrd bugs is
>
>        Open device
>                Kernel issues hotplug message
>                        Hotplug script opens same device (BUG)

The kernel calls modprobe for something, modprobe tries to log an
error, and the kernel calls modprobe again. Bug! No hotplug involved.

>                                Kernel issues hotplug message
>                                .....
>                                Kernel detects this is stuck
>                                Kernel replies with -ENODEV/-ENXIO to try
> and rescue itself from buggy initrd scripts

Totally wrong, It never was that way.

> That is how it has worked since we first had script based module
> requesting which is some years now.

Please update your idea of hotplug and the kernel module loader, you
are on the totally wrong track.

Thanks,
Kay
--
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/