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: <20200727064957.GB2317@lst.de>
Date:   Mon, 27 Jul 2020 08:49:57 +0200
From:   Christoph Hellwig <hch@....de>
To:     hpa@...or.com
Cc:     Christoph Hellwig <hch@....de>, 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 Sun, Jul 26, 2020 at 11:36:15PM -0700, hpa@...or.com wrote:
> >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.

I don't think it will be all that simple.  But given that linux-next
is just missing one series Al was already ok with to kill off set_fs
entirely for about half of our architectures I'd rather go ahead with
this series.  If you can send a series mapping user memory that actually
cleans things up on top of it I'm not going to complain, but I'm not
sure it really is going to be all that much cleaner.