linux-kernel - Re: [PATCH v3 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 1 Mar 2019 12:21:58 -0500
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        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, Guenter Roeck <groeck@...omium.org>,
        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,
        linux-trace-devel@...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>,
        qais.yousef@....com, rdunlap@...radead.org, rostedt@...dmis.org,
        Shuah Khan <shuah@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, yhs@...com
Subject: Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to
 extend the kernel

On Fri, Mar 01, 2019 at 04:03:09PM +0900, Masami Hiramatsu wrote:
> Hi Joel,
> 
> On Thu, 28 Feb 2019 22:26:11 -0500
> Joel Fernandes <joel@...lfernandes.org> wrote:
> 
> > On Fri, Mar 01, 2019 at 11:28:26AM +0900, Masami Hiramatsu wrote:
[..]
> > There are many usecases for this, I have often run into issues with Linux
> > over the years not only with Android, but other distros, where I boot custom
> > kernels with no linux-headers package. This is quite painful. It is
> > convenient to have it as /proc file since the file is dependent on kernel
> > being booted up and this will work across all Linux distros and systems. I
> > feel that if you can keep an open mind about it, you will see that a lot of
> > people will use this feature if it is accepted and there is a lot of positive
> > feedback in earlier posts of this set.
> 
> I don't complain about having headers for custom boot kernel. I agree with you
> that having kernel headers for debugging is always good. :)
> So google recommends built-in, it is reasonable.

Ok, thanks :)

> > > > > > The code to read the headers is based on /proc/config.gz code and uses
> > > > > > the same technique to embed the headers.
> > > > > > 
> > > > > > To build a module, the below steps have been tested on an x86 machine:
> > > > > > modprobe kheaders
> > > > > > rm -rf $HOME/headers
> > > > > > mkdir -p $HOME/headers
> > > > > > tar -xvf /proc/kheaders.tar.xz -C $HOME/headers >/dev/null
> > > > > > cd my-kernel-module
> > > > > > make -C $HOME/headers M=$(pwd) modules
> > > > > > rmmod kheaders
> > > > > 
> > > > > It seems a bit complex, but no difference from compared with carrying
> > > > > kheaders.tar.gz. I think we would better have a psudo filesystem
> > > > > which can mount this compressed header file directly :) Then it becomes
> > > > > simpler, like
> > > > > 
> > > > > modprobe headerfs
> > > > > mkdir $HOME/headers
> > > > > mount -t headerfs $HOME/headers
> > > > > 
> > > > > And this doesn't consume any disk-space.
> > > > 
> > > > I felt using a compressed tar is really the easiest way because of all the
> > > > tools are already available.
> > > 
> > > As I asked above, if the pure tarball is useful, you can simply ask vendors
> > > to put the header tarball on their vendor directory. I feel making it as
> > > a module is not a right way.
> > 
> > I don't see what is the drawback of making it a module, it makes it well
> > integrated into kernel build and ecosystem. I also didn't see any
> > justification you're providing about why it cannot be a module. If you go
> > through this and earlier threads, a lot of people are Ok with having a module
> > option. And I asked several top kernel maintainers at LPC and many people
> > suggested having it as a module.
> 
> I meant, if we have a tarball, we don't need any operation of loading/unloading
> kmodules. But if we have this as built-in, yes, this would be much easier to
> deploy it to device.
> 
> Anyway, having that option (make it as a module) is not bad. IMHO, that may
> be more complicated than just have a tarball file, but it is a user's choice.
> 
> OK, now I understand it.

Sounds good. :) Just sent out v4.

thanks,

 - Joel