linux-kernel - Re: [PATCH 18/23] init: open code setting up stdin/stdout/stderr

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: <366377E2-6F19-45E1-9285-CFA5E660C6B5@zytor.com>
Date:   Sun, 26 Jul 2020 23:36:15 -0700
From:   hpa@...or.com
To:     Christoph Hellwig <hch@....de>
CC:     Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org,
        Song Liu <song@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-raid@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 18/23] init: open code setting up stdin/stdout/stderr

On July 26, 2020 11:24:25 PM PDT, Christoph Hellwig <hch@....de> wrote:
>On Sun, Jul 26, 2020 at 11:20:41PM -0700, hpa@...or.com wrote:
>> On July 26, 2020 8:05:34 PM PDT, Al Viro <viro@...iv.linux.org.uk>
>wrote:
>> >On Tue, Jul 14, 2020 at 09:04:22PM +0200, Christoph Hellwig wrote:
>> >> Don't rely on the implicit set_fs(KERNEL_DS) for ksys_open to
>work,
>> >but
>> >> instead open a struct file for /dev/console and then install it as
>FD
>> >> 0/1/2 manually.
>> >
>> >I really hate that one.  Every time we exposed the internal details
>to
>> >the fucking early init code, we paid for that afterwards.  And this
>> >goes over the top wrt the level of details being exposed.
>> >
>> >_IF_ you want to keep that thing, move it to fs/file.c, with dire
>> >comment
>> >re that being very special shite for init and likely cause of
>> >subsequent
>> >trouble whenever anything gets changed, a gnat farts somewhere, etc.
>> >
>> >	Do not leave that kind of crap sitting around init/*.c; KERNEL_DS
>> >may be a source of occasional PITA, but here you are trading it for
>a
>> >lot
>> >worse one in the future.
>> 
>> Okay... here is a perhaps idiotic idea... even if we don't want to
>run stuff in actual user space, could we map initramfs into user space
>memory before running init (execing init will tear down those mappings
>anyway) so that we don't need KERNEL_DS at least?
>
>Err, why?  The changes have been pretty simple, and I'd rather not come
>up with new crazy ways just to make things complicated.

Why? To avoid this neverending avalanche of special interfaces and layering violations. Neatly deals with non-contiguous contents and initramfs in device memory, etc. etc. etc.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.