linux-kernel - Re: [PATCH 1/2] 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]

Date:   Thu, 7 Feb 2019 18:50:42 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     linux-kernel@...r.kernel.org,
        Alexandre Torgue <alexandre.torgue@...com>,
        Andrew Morton <akpm@...ux-foundation.org>, ast@...nel.org,
        atishp04@...il.com, dancol@...gle.com,
        Dan Williams <dan.j.williams@...el.com>,
        gregkh@...uxfoundation.org, Ingo Molnar <mingo@...hat.com>,
        Jonathan Corbet <corbet@....net>, karim.yaghmour@...rsys.com,
        Kees Cook <keescook@...omium.org>, kernel-team@...roid.com,
        linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org,
        Manoj Rao <linux@...ojrajarao.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        paulmck@...ux.vnet.ibm.com,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        rdunlap@...radead.org, Shuah Khan <shuah@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        yhs@...com
Subject: Re: [PATCH 1/2] Provide in-kernel headers for making it easy to
 extend the kernel

On Thu, 7 Feb 2019 18:39:02 -0500
Joel Fernandes <joel@...lfernandes.org> wrote:
> > > +
> > > +spath="$(dirname "$(readlink -f "$0")")"
> > > +
> > > +rm -rf $1.tmp
> > > +mkdir $1.tmp
> > > +
> > > +for f in "${@:2}";
> > > +	do find "$f" ! -name "*.c" ! -name "*.o" ! -name "*.cmd" ! -name ".*";  
> > 
> > I wonder if it is a good idea to pick all files in the directories
> > defined in ikh_file_list, and not just explicitly list what we want,
> > with a '*.h' and such?  
> 
> I also need few files in the archive that are not .h, these don't take up
> much space but are needed to make an out-of-tree kernel module build succeed.
> 
> One of my goals with this was to make a self-contained module that could be
> loaded to build other modules. Majority of the files are kernel headers, but
> some are not, such as Module.symvers and other scripts. Then one can run
> systemtap on Android which can be made to build modules using the embedded
> headers.

Have you audited what it picks up? My main concern is that we start
adding files that are not necessary or just simply added in the
directory that are not needed for this.

> 
> > > +done | cpio -pd $1.tmp
> > > +
> > > +for f in $(find $1.tmp); do
> > > +	$spath/strip-comments.pl $f
> > > +done
> > > +
> > > +tar -Jcf $1 -C $1.tmp/ . > /dev/null
> > > +
> > > +rm -rf $1.tmp
> > > diff --git a/scripts/strip-comments.pl b/scripts/strip-comments.pl
> > > new file mode 100755
> > > index 000000000000..f8ada87c5802
> > > --- /dev/null
> > > +++ b/scripts/strip-comments.pl
> > > @@ -0,0 +1,8 @@
> > > +#!/usr/bin/perl -pi
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +
> > > +# This script removes /**/ comments from a file, unless such comments
> > > +# contain "SPDX". It is used when building compressed in-kernel headers.
> > > +
> > > +BEGIN {undef $/;}
> > > +s/\/\*((?!SPDX).)*?\*\///smg;  
> > 
> > Hmm, I'm also wondering if we could us the C pre-processor for the
> > stripping of everything from the header file. We would then even get
> > the header files only having what is necessary for the running kernel.  
> 
> I thought about this too. An issue with that is it is going to be really slow
> due to the large number of headers. The other is, I think it will actually
> make the headers bigger and take up more space - because all the include
> directives will also be expanded and have more duplication. Let me know if I
> missed something though.
> 

Good point about the duplication. I was mostly thinking of getting rid
of "#ifdef" blocks.

BTW, these comments are more of a "have you thought about this" and not
really action comments.

-- Steve