linux-kernel - Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

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]

Date:   Wed, 6 Mar 2019 16:36:46 -0800
From:   Daniel Colascione <dancol@...gle.com>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     Pavel Machek <pavel@....cz>,
        Joel Fernandes <joel@...lfernandes.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>, ast@...nel.org,
        atish patra <atishp04@...il.com>,
        Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
        Jan Kara <jack@...e.cz>, Jonathan Corbet <corbet@....net>,
        Karim Yaghmour <karim.yaghmour@...rsys.com>,
        Kees Cook <keescook@...omium.org>, kernel-team@...roid.com,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Manoj Rao <linux@...ojrajarao.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Paul McKenney <paulmck@...ux.vnet.ibm.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>, rostedt@...dmis.org,
        Thomas Gleixner <tglx@...utronix.de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        yhs@...com
Subject: Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

On Wed, Mar 6, 2019 at 4:33 PM H. Peter Anvin <hpa@...or.com> wrote:
>
> On 3/6/19 3:37 PM, Daniel Colascione wrote:
> >
> > I just don't get the opposition to Joel's work. The rest of the thread
> > already goes into detail about the problems with pure-filesystem
> > solutions, and you and others are just totally ignoring those
> > well-thought-out rationales for the module approach and doing
> > inflooping on "lol just use a tarball". That's not productive.
> >
>
> You might think they are well thought out, but at least from what I can
> tell they seem completely spurious.

That sentence is a general-purpose objection to literally anything.
Anything so general is useless. If you want to claim that the
rationale behind the work is inadequate, you have to explain why the
use cases that it enables are either illegitimate or amenable to other
solutions, not just call them spurious.