linux-kernel - [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: <5ebec282-57b0-6ebe-0876-ce0dd7b0c11c@metux.net>
Date:   Thu, 7 Mar 2019 21:41:24 +0100
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Daniel Colascione <dancol@...gle.com>
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: [RFC] Provide in-kernel headers for making it easy to extend the
 kernel

On 07.03.19 02:49, Daniel Colascione wrote:

> 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. :-)

Fix these emulators ?

> 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.

Ok, but the filesystem where the modules live is mountable, right ?

> 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

I can define such an interface with a few words:

* the kernel headers lives in a (compressed) squashfs image in the
  module directory for the corresponding kernel version:
      /lib/modules/<version>-<flavour>/headers.img"
* this image shall be mounted at a canonical mountpoint, eg:
      /usr/src/linux-headers-<version>-<flavour>
* the kernel needs to support squashfs (may be module or built-in)

That's it. I don't need to touch a single line of kernel code for that,
just a very simple and small convention.

> have a chance to make very useful tools work transparently everywhere,
> and without additional work across a fragmented and uncoordinated
> ecosystem. 

Why not instead starting to clean up your fragmented and uncoordinated
ecosystem ? :o

> That's not nothing!

It's nothing more that we already have built-in for aeons.

> 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.

So, adding a few LOC in Android build machinery for just creating an
archive/squashfs is such a complicated things that takes many years ?

> Human factors are just as important as technical ones,

Human factors like people just not willing to learn the fundamental
basics of the operating they're customizing ?

> 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. 

So, if userland folks are incapable of doing pretty simple things,
put a complex machinery into the kernel ?

> It'd be different if we were
> working in a more-coordinated system NT or FreeBSD, 

Ah, NT. Windows. The platform where everybody rolls his own monstreaus
drivers stacks (eg. several megabytes for trivialities like a CAN
adapter or about a gigabyte for a bunch of adc cards), usually all with
their own private userland api, because the OS vendor just doesn't
manage to provide generic subsystems for common stuff.

The one where applications are usually 10 times bigger and all come
with their own, private installer, just because there's no coordinated
package management and distros.

> but this is Linux,

No, this is *Android* we're talking about.

In GNU/Linux world, the problem you're trying to solve here already
*is* solved since aeons. Entirely in userland.

> where fragmentation starts as soon as you exit ring zero.

Such fragmentation like virtually any device vendor forking it's own
private kernel for each model, doing a huge bunch of pretty crude
hacks and dropping all maintenance as soon as the next model coming
up on the horizon ?

> Practically speaking, the only universal mechanism is to bake something
> into the kernel image or one of its modules.

Aha, and when do we start moving widget toolkits and html renderers
into the kernel ? :o

--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287