lkml.org 
[lkml]   [2019]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
On Sat, Mar 09, 2019 at 12:40:01PM +0100, Geert Uytterhoeven wrote:
> > Signing keys should be kept secure, or better yet, just deleted entirely
> > after creating and signing with them. That's what I do for my kernels
> > and I'm pretty sure that some distros also do this. That way there's no
> > chance that someone else can sign a module and have it loaded without
> > detection, which is what signing is supposed to prevent from happening.
>
> If you want that kind of security, there's no point in allowing to extend the
> kernel by building more kernel modules after deployment.

That's not what these files are for (in the original user's case). They
want these for doing tracing/ebpf stuff, which require kernel headers to
build against.

> "Raw kernel headers also cannot be copied into the filesystem like they
> can be on other distros, due to licensing and other issues. There's no
> linux-headers package on Android."
>
> What's the licensing issue? What's the (legal) difference between having
> the headers on the file system, and having a kernel module including the
> headers on the file system?

There is no licensing issue, see my follow-up comment about that.

It's all in ease-of-use here. You want to build a trace function
against a running kernel, and now you have the header files for that
specific kernel right there in the kernel itself to build against. It
doesn't get easier than that.

thanks,

greg k-h

\
 
 \ /
  Last update: 2019-03-09 13:12    [W:0.080 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site