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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190120155838.GA23827@google.com>
Date:   Sun, 20 Jan 2019 10:58:38 -0500
From:   Joel Fernandes <joel@...lfernandes.org>
To:     hpa@...or.com
Cc:     Daniel Colascione <dancol@...gle.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>, ast@...nel.org,
        atishp04@...il.com, Borislav Petkov <bp@...en8.de>,
        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,
        "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 Sat, Jan 19, 2019 at 03:44:48PM -0800, hpa@...or.com wrote:
> On January 19, 2019 3:25:03 PM PST, Joel Fernandes <joel@...lfernandes.org> wrote:
> >On Sat, Jan 19, 2019 at 12:43:35PM -0500, Daniel Colascione wrote:
> >> On Sat, Jan 19, 2019 at 11:27 AM Joel Fernandes
> ><joel@...lfernandes.org> wrote:
> >> >
> >> > On Sat, Jan 19, 2019 at 09:25:32AM +0100, Greg KH wrote:
> >> > > On Fri, Jan 18, 2019 at 05:55:43PM -0500, Joel Fernandes wrote:
> >> > > > --- /dev/null
> >> > > > +++ b/kernel/kheaders.c
> >> 
> >> Thanks a ton for this work. It'll make it much easier to do cool
> >> things with BPF.
> >
> >You're welcome, thanks.
> >
> >> One question: I can imagine wanting to probe
> >> structures that are defined, not in headers, but in random
> >> implementation files. Would it be possible to optionally include
> >*all*
> >> kernel source files?
> >
> >That would be prohibitively too large to justify keeping it in memory,
> >even
> >compressed. Arguably, such structures should be moved into include/ if
> >modules or whatever is extending the kernel like eBPF needs them.
> >
> >> If not, what about a hash, so we could at least
> >> do precise correlation between a candidate local tree and what's
> >> actually on device?
> >
> >That would make a tool too difficult to write wouldn't it, since they
> >you have to
> >correlate every possible hash and keep updating eBPF tools with new
> >hashes -
> >probably not scalable. I think what you want is to use the kernel
> >version to
> >assume what such internal structures look like although that's still
> >not
> >robust.
> >
> >> BTW, I'm not sure that the magic constants you've defined are long
> >> enough.  I'd feel more comfortable with two UUIDs (16 bytes each).
> >
> >Ok, I'll expand it.
> >
> >> I'd also strongly consider LZMA compression: xz -9 on the kernel
> >> headers (with comments) brings the size down to 5MB, compared to the
> >> 7MB I get for gzip -9. Considering that this feature is optional, I
> >> think it's okay to introduce a dependency on widespread modern
> >> compression tools. (For comparison, bzip2 -9 gets us 6MB.)
> >
> >Ok, I'll look into LZMA. Thanks for checking the compression sizes.
> >
> >- Joel
> 
> Don't use lzma, use xz if you are going to do something.

Ok, sounds good.

> However, it seems unlikely to me that someone not willing to spend the space in the filesystem will spend unswappable kernel memory.
> 
> It would seem that a far saner way to do this is to use inittmpfs or perhaps an auxiliary "ktmpfs" so it can at least be swapped out if you have swap.

But this is already possible with the proposed solution, you would load the
module, extract it into a tmpfs, and unload the module. TMPFS pages can
already be swapped.

thanks,

 - Joel