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:   Sat, 19 Jan 2019 11:26:44 -0500
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>, ast@...nel.org,
        atishp04@...il.com, Borislav Petkov <bp@...en8.de>,
        dancol@...gle.com, "H. Peter Anvin" <hpa@...or.com>,
        Ingo Molnar <mingo@...hat.com>, Jan Kara <jack@...e.cz>,
        Jonathan Corbet <corbet@....net>, karim.yaghmour@...rsys.com,
        Kees Cook <keescook@...omium.org>, kernel-team@...roid.com,
        linux-doc@...r.kernel.org, Manoj Rao <linux@...ojrajarao.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        paulmck@...ux.vnet.ibm.com,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        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 Sat, Jan 19, 2019 at 11:36:06AM +0100, Greg KH wrote:
> On Sat, Jan 19, 2019 at 02:28:00AM -0800, Christoph Hellwig wrote:
> > This seems like a pretty horrible idea and waste of kernel memory.
> 
> It's only a waste if you want it to be a waste, i.e. if you load the
> kernel module.
> 
> This really isn't any different from how /proc/config.gz works.

Yes, that's right, it can be built as a module and loaded and unloaded on
demand to free the kernel memory. Also such a module can be made a part of
the initrd image itself (like other kernel modules that are built into an
initrd), so this solution is already initrd-ready if anyone really wants it
that way.

> > Just add support to kbuild to store a compressed archive in initramfs
> > and unpack it in the right place.
> 
> I think the issue is that some devices do not use initramfs, or switch
> away from it after init happens or something like that.  Joel has all of
> the looney details that he can provide.

Initially I had written this as an image embedded into an init section,
similar to the initramfs. On boot if a boot argument was passed, then the
archive embedded was allocated additional non-init kernel memory to store it for
retrieval through /proc. After that, the image that's embedded would be
dropped entirely as its init memory. If no boot argument was passed, then no
additional memory is used at all. Even though I got that working, I decided
not to go with it because it was clunky because: 1. It required modification
of the linker scripts in the kernel to embed the image into the init section,
and also required a boot argument to be passed which makes the decision on
whether to have headers as a boot-time decision than a post-boot decision.
For these reasons, it is much cleaner to just have a loadable module and make
it on-demand, as I am doing in this patch similar to what /proc/config.gz
does.

thanks!

 - Joel