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]

Message-ID: <20081207115820.1c595877@lxorguk.ukuu.org.uk>
Date:	Sun, 7 Dec 2008 11:58:20 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Evgeniy Polyakov <zbr@...emap.net>
Cc:	Kay Sievers <kay.sievers@...y.org>, linux-kernel@...r.kernel.org
Subject: Re: Runaway loop with the current git.

> > So we have a buggy modprobe... 
> 
> Which nevertheless should not break boot process...

Now you are talking complete crap. If init crashes what happens. If I
have the wrong root fs listed what happens ?

Gee it breaks. Early userspace actually does have to be correct.

> should not hung. Detect recursion, do not allow more than 1-2-3
> simultaneous modprobes, whatever, but do not say, that kernel behaves
> that bad just because userspace is allowed to do that.

Please read the code: that is what we do. That is *WHY* you got the
runaway modprobe message. It was caught but despite that the broken
initrd failed to recover. We've had that feature for years.

> And what's the argument of being close to a release? Do you propose to
> hide the head into the sand and point a finger to anyone else saying its
> not a kernel's problem? If prerelease has a bug, it should be fixed, and
> not hidden under the cover.

Its an incredibly obscure corner case. It is not appropriate to totally
trash years of kernel testing by panic re-ordering some init functions
just before a release. You will undoubtedly harm more people than you'll
please.

> What about storing a small stack of recently requested device ids, and
> if new request is about to ask one from that stack, return error? I can
> cook up the patch tomorrow.

That would be an interesting experiment for 2.6.29 however we do requests
in lots of different formats so it might be a bit more complex. You could
store the last few strings. However the existing runaway code caught it
and will have resulted in the -ENXIO path occuring anyway so I don't see
what your "change" will achieve.

Alan
--
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/