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: <20190307205505.GB30028@kroah.com>
Date:   Thu, 7 Mar 2019 21:55:05 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc:     Daniel Colascione <dancol@...gle.com>,
        "H. Peter Anvin" <hpa@...or.com>, Pavel Machek <pavel@....cz>,
        Joel Fernandes <joel@...lfernandes.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 Thu, Mar 07, 2019 at 09:41:24PM +0100, Enrico Weigelt, metux IT consult wrote:
> 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.

Ick, no, no more squashfs please, let's just kill that mess once and for
all :)

Again, putting this in a simple compressed tar image allows anyone to do
whatever they need to with this.  If they want a full filesystem,
uncompress it and use it there.  If they just want it in-memory where
they can uncompress it and then discard it, that works too.

And if no one wants this, just don't select the config option and do not
load the module with this data in it.  Just like /proc/config.gz is
today.

thanks,

greg k-h