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]

Message-ID: <CAKOZuevksKGAPif_pUYVzFpbuBCxOZ5WzT6ukLCYm4TzyLUTMw@mail.gmail.com>
Date:   Wed, 6 Mar 2019 17:49:23 -0800
From:   Daniel Colascione <dancol@...gle.com>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc:     "H. Peter Anvin" <hpa@...or.com>, 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 5:23 PM Enrico Weigelt, metux IT consult
<lkml@...ux.net> wrote:
>
> On 07.03.19 01:33, Daniel Colascione wrote:
>
> > *There* *may* *be* *no* *filesystem*.
>
> A Linux system w/o any filesystem at all ? Well, that's interesting.

Entirely FS-less operation is uncommon, granted. :-) I guess I've just
spent too much time debugging emulators that refuse to mount their
root filesystems. :-) There are legitimate reasons why a device's
filesystems might not be rw-mountable though, and I can imagine a
world where I want to attach tracing tools *very* early.

> > The only thing the kernel can really guarantee is its own> existence --- it should be entire in itself.
>
> I vaguely recall some option for linking in an initrd ... does this
> still exist ?
>
> > If I'm hacking on an> Android kernel and say "fastboot boot mykernel" without making any>
> changes to the device's boot filesystem, I should still be able to use>
> tracing tools that rely on knowing the headers for the kernel with
>
> Fix fastboot to support initrd or use a remote filesystem ?

Sure. There's some support for a ramdisk already in fastboot. But just
including a blob in initrd doesn't *automatically* make it available
to userspace in any uniform way. With Joel's approach --- which
defines both a propagation mechanism and an access interface --- we
have a chance to make very useful tools work transparently everywhere,
and without additional work across a fragmented and uncoordinated
ecosystem. That's not nothing! While I appreciate the purity merits of
a file-based approach, insisting on it will lead to a world where
it'll be many more years before we can apply these powerful analysis
tools universally. Human factors are just as important as technical
ones if you want to actually get anything done, and in this case, a
consideration of the human factors points toward the kernel as
coordination point for kernel metadata. It'd be different if we were
working in a more-coordinated system NT or FreeBSD, but this is Linux,
where fragmentation starts as soon as you exit ring zero.

That said, I think it's fair to want the configuration blob to be
swappable and removable even in a monolothic, no-module system. There
are lots of ways of meeting these requirements.

> I'm doing embedded development all the day, and one of the first things
> I usually set up for a project is an fully automatic netboot (or at
> least usb boot). Shouldn't be so hard, and is a more generic solution.

Yeah. I think every embedded developer quickly developers a rich set
of shell scripts for this stuff. That's part of my point: if we can
pull it off, existing toolsets, which we can't possibly change all at
once, should properly propagate this kernel metadata without having to
even realize that they're doing it. Practically speaking, the only
universal mechanism is to bake something into the kernel image or one
of its modules.