linux-kernel - Re: [GIT PULL] remove ksys_mount() and ksys

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: <20191218075119.GA186397@light.dominikbrodowski.net>
Date:   Wed, 18 Dec 2019 08:51:19 +0100
From:   Dominik Brodowski <linux@...inikbrodowski.net>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Jesse Barnes <jsbarnes@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] remove ksys_mount() and ksys_dup()

On Tue, Dec 17, 2019 at 10:57:43PM +0000, Al Viro wrote:
> Seriously, these parts of init/* ought to be treated as userland code
> that runs in kernel mode mostly because it's too much PITA to arrange
> building a static ELF binary and linking it into the image.

Well, we have had the infrastructure for fork_usermode_blob() in the kernel
since May 2018, though it is not really used so far (the bpfilter blob is
just reporting its existence, and not doing anything substantial). Probably,
significant parts of init/* could be migrated to such a blob. Would that be
an alternative generally preferred, or is its dependence on CC_CAN_LINK a
showstopper?

FWIW, non-initramfs boot code is considered to be "legacy" since 2.6.16, see
filesystems/ramfs-rootfs-initramfs.txt:

| Today (2.6.16), initramfs is always compiled in, but not always used.  The
| kernel falls back to legacy boot code that is reached only if initramfs does
| not contain an /init program.  The fallback is legacy code, there to ensure a
| smooth transition and allowing early boot functionality to gradually move to
| "early userspace" (I.E. initramfs).
|
| ...
|
| This kind of complexity (which inevitably includes policy) is rightly handled
| in userspace.  Both klibc and busybox/uClibc are working on simple initramfs
| packages to drop into a kernel build.
|
| The klibc package has now been accepted into Andrew Morton's 2.6.17-mm tree.
| The kernel's current early boot code (partition detection, etc) will probably
| be migrated into a default initramfs, automatically created and used by the
| kernel build.

That plan seems to have been obsoleted long ago, right?

Thanks,
	Dominik