linux-kernel - Re: [PATCH v2 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] [day] [month] [year] [list]

Message-ID: <20190219172550.GB239374@google.com>
Date:   Tue, 19 Feb 2019 12:25:50 -0500
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     linux-kernel@...r.kernel.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to
 extend the kernel

On Tue, Feb 19, 2019 at 09:05:31AM +0300, Alexey Dobriyan wrote:
> > /proc/kheaders.txz
> 
> This is gross.

It is a bit gross, but it solves a long standing problem we have nicely. And
there's also /proc/config.gz.

> > The feature is also buildable as a module just in case the user desires
> > it not being part of the kernel image. This makes it possible to load
> > and unload the headers on demand. A tracing program, or a kernel module
> > builder can load the module, do its operations, and then unload the
> > module to save kernel memory.
> 
> Please explain how keeping headers on the filesystem is not OK due
> to "licensing and other issues" but keeping a module on the filesystem
> is OK.

In the Android ecosystem, the Android teams only provide a "userspace system
image" which goes on the system partition of the flash. This image is not GPL
and doesn't contain anything GPL. It is thus not possible to put kernel
headers on the system image and I already had many discussions on the subject
with the teams, it is something that is just not done. Now for kernel
modules, there's another image called the "vendor image" which is flashed
onto the vendor parition, this is where kernel modules go. This vendor image
is not provided by Google for non-Pixel devices. So we have no control over
what goes there. We do know that kernel modules that are enabled will go
there, and we do have control over enforcing that certain kernel modules
should be built and available as they are mandatory for Android to function
properly (and we can enforce this as a case of Android device compliance).

So this solves the problem rather nicely. It is also useful for non-Android
usecases where a linux-headers package needs to be installed for tracing
programs. With this feature, such a package install step is not needed.

> > > I can route it via bpf-next tree if there are no objections.
> 
> Please don't.

Why not? You do know that eBPF based compilation needs to process kernel
headers to build the eBPF program? This was primarily inspired by problems
with getting eBPF to work, but it also applies to other trace tools like
systemtap that build for a module backend. In fact for Android, I am planning
to have facilities to compile code for a module backend as well.

> IKHD_ST IKHD_ED are bogus artifacts as others mentioned.
> proc_create(S_IFREG) is redundant.
> seq_file.h is not needed as is THIS_MODULE.
> I'd say such data should live in their own section for easy extraction
> with "objdump -j", something /proc/config.gz never did.

Thanks for the suggestions, I will look into these and refresh my series. My
first priority right now is to make incremental builds work. Other than
these, other changes are mostly cosmetic so I can address them after. Of
course I will address everything before posting again.

 - Joel