linux-kernel - Re: [PATCH v2 00/36] remove in-kernel syscall invocations (part 1)

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+55aFwCTRNCm26RKtBti9rYZghsrt4G8eeG=Byj4dZrzr-PEw@mail.gmail.com>
Date:   Fri, 16 Mar 2018 09:47:52 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 00/36] remove in-kernel syscall invocations (part 1)

On Fri, Mar 16, 2018 at 7:20 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Fri, Mar 16, 2018 at 01:54:23AM -0700, Christoph Hellwig wrote:
>>
>> A lot of the issues here is that the initramfs / do_mount code
>> is written as if it was user space code, but in kernel space.  E.g.
>> using file desriptors etc.

Yeah, some of it could probably pass a 'struct filp *' around instead.

So there are definitely things we could do once we no longer use the
raw system calls anyway.

> ... and I still wonder if it would make more sense to kick that crap
> out into userland.

Oh, no, let's not do that. Even if we were to still maintain control
of user space, it would mean yet another nasty special case for the
compiler and linker scripts and for our initrd generation.

And if we were to spin it out entirely (aka udevd and friends), it
would become one of those nasty situations where there's some *very*
odd code that we need to keep compatibility with because you might run
a new kernel and some old "pre-init user code" stuff.

I'd much rather just make it look more like kernel code.

And maybe remove some code entirely. Christ, we still have the logic
in there to change *floppies* if the ramdisk doesn't fit on a single
floppy disk.  Does it work? Probably not, since presumably it hasn't
been used in ages. But it's still there.

So some of the ioctl's etc are due to insanely old legacy cases.

                 Linus