linux-kernel - Re: [PATCH] init:main.c: start 'usermodehelper

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: <CA+55aFyP5NcNTuHTjrBY9MFbGM793TiMs6Ejnk8+aU=LYefKFg@mail.gmail.com>
Date:	Thu, 29 Sep 2011 07:37:31 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	wang yanqing <udknight@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] init:main.c: start 'usermodehelper_enable()' a little early

On Thu, Sep 29, 2011 at 1:57 AM, wang yanqing <udknight@...il.com> wrote:
>
> maybe uvesafb has some specific thing that it requires a userspace
> helper application called 'v86d' to work!
> I will try to make uvesafb workaround it, but i don't know whether it
> will work, and splash boot *really* need
> early init.

Ok. I guess we cannot avoid this. I really would have preferred to run
the kernel init routines without usermodehelper enabled, but it looks
like reality doesn't care about my wishes.

Your "move it up to before all initcalls" works, and seems to be the
simplest solution. I considered doing this when we mount the root
filesystem, but depending on config options that is in multiple
places. We could do the usermode helper enable as a
rootfs_initcall()..

I'm nervous about this. Enabling the usermode helpers too early can
re-introduce the bug where we do it *much* too early before everything
is initialized. But yes, uvesafb clearly does depend on being able to
execute v86d from the root filesystem.

So I  think I'll just have to apply your patch. The alternatives look uglier.

Thanks for the report and the debug help,

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