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:4.437 / U:0.552 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site