All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Joel Fernandes <joel@joelfernandes.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>,
	atish patra <atishp04@gmail.com>,
	Daniel Colascione <dancol@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Guenter Roeck <groeck@chromium.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Karim Yaghmour <karim.yaghmour@opersys.com>,
	Kees Cook <keescook@chromium.org>,
	Android Kernel Team <kernel-team@android.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	linux-trace-devel@vger.kernel.org,
	Manoj Rao <linux@manojrajarao.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Qais Yousef <qais.yousef@arm.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Shuah Khan <shuah@kernel.org>, Yonghong Song <yhs@fb.com>
Subject: Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
Date: Sat, 9 Mar 2019 13:11:41 +0100	[thread overview]
Message-ID: <20190309121141.GA30173@kroah.com> (raw)
In-Reply-To: <CAMuHMdUT+UGt9p2QhOXzAtCUmqy-a8YN-ceDa-0qANJE53pWBA@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: gregkh at linuxfoundation.org (Greg KH)
Subject: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
Date: Sat, 9 Mar 2019 13:11:41 +0100	[thread overview]
Message-ID: <20190309121141.GA30173@kroah.com> (raw)
In-Reply-To: <CAMuHMdUT+UGt9p2QhOXzAtCUmqy-a8YN-ceDa-0qANJE53pWBA@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg KH)
Subject: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
Date: Sat, 9 Mar 2019 13:11:41 +0100	[thread overview]
Message-ID: <20190309121141.GA30173@kroah.com> (raw)
Message-ID: <20190309121141.h5fjB1UO_qqSVfRFeHuTEy7FALwuYUj-9l6SsXQIe2M@z> (raw)
In-Reply-To: <CAMuHMdUT+UGt9p2QhOXzAtCUmqy-a8YN-ceDa-0qANJE53pWBA@mail.gmail.com>

On Sat, Mar 09, 2019@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

  reply	other threads:[~2019-03-09 12:11 UTC|newest]

Thread overview: 142+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 16:08 [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel Joel Fernandes (Google)
2019-03-01 16:08 ` Joel Fernandes (Google)
2019-03-01 16:08 ` joel
2019-03-01 16:08 ` [PATCH v4 2/2] Add selftests for module build using in-kernel headers Joel Fernandes (Google)
2019-03-01 16:08   ` Joel Fernandes (Google)
2019-03-01 16:08   ` joel
2019-03-02 21:59 ` [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel kbuild test robot
2019-03-02 21:59   ` kbuild test robot
2019-03-02 21:59   ` lkp
2019-03-03 16:11   ` Joel Fernandes
2019-03-03 16:11     ` Joel Fernandes
2019-03-03 16:11     ` joelaf
2019-03-06 12:26     ` Masahiro Yamada
2019-03-06 12:26       ` Masahiro Yamada
2019-03-06 12:26       ` yamada.masahiro
2019-03-06 17:49       ` Joel Fernandes
2019-03-06 17:49         ` Joel Fernandes
2019-03-06 17:49         ` joel
2019-03-07  4:59         ` Masahiro Yamada
2019-03-07  4:59           ` Masahiro Yamada
2019-03-07  4:59           ` yamada.masahiro
2019-03-07 14:54           ` Joel Fernandes
2019-03-07 14:54             ` Joel Fernandes
2019-03-07 14:54             ` joel
2019-03-07 23:23       ` Justin Capella
2019-03-07 23:23         ` Justin Capella
2019-03-07 23:23         ` justincapella
2019-03-06 18:16     ` Joel Fernandes
2019-03-06 18:16       ` Joel Fernandes
2019-03-06 18:16       ` joel
2019-03-07  4:54       ` Masahiro Yamada
2019-03-07  4:54         ` Masahiro Yamada
2019-03-07  4:54         ` yamada.masahiro
2019-03-03  2:04 ` kbuild test robot
2019-03-03  2:04   ` kbuild test robot
2019-03-03  2:04   ` lkp
2019-03-04 14:00 ` Qais Yousef
2019-03-04 14:00   ` Qais Yousef
2019-03-04 14:00   ` qais.yousef
2019-03-05 16:27   ` Joel Fernandes
2019-03-05 16:27     ` Joel Fernandes
2019-03-05 16:27     ` joel
2019-03-04 22:48 ` Dietmar Eggemann
2019-03-04 22:48   ` Dietmar Eggemann
2019-03-04 22:48   ` dietmar.eggemann
2019-03-05 16:25   ` Joel Fernandes
2019-03-05 16:25     ` Joel Fernandes
2019-03-05 16:25     ` joel
2019-03-07  8:58 ` Geert Uytterhoeven
2019-03-07  8:58   ` Geert Uytterhoeven
2019-03-07  8:58   ` geert
2019-03-07 15:03   ` Joel Fernandes
2019-03-07 15:03     ` Joel Fernandes
2019-03-07 15:03     ` joel
2019-03-07 15:23     ` Greg KH
2019-03-07 15:23       ` Greg KH
2019-03-07 15:23       ` gregkh
2019-03-07 16:54       ` Joel Fernandes
2019-03-07 16:54         ` Joel Fernandes
2019-03-07 16:54         ` joel
     [not found]       ` <20190318185742.109dee5c@alans-desktop>
2019-03-18 19:11         ` Daniel Colascione
2019-03-18 21:11         ` Karim Yaghmour
2019-03-18 21:11           ` Karim Yaghmour
2019-03-18 21:11           ` karim.yaghmour
2019-03-08  8:53     ` Geert Uytterhoeven
2019-03-08  8:53       ` Geert Uytterhoeven
2019-03-08  8:53       ` geert
2019-03-08 13:42       ` Joel Fernandes
2019-03-08 13:42         ` Joel Fernandes
2019-03-08 13:42         ` joel
2019-03-08 13:57         ` Enrico Weigelt, metux IT consult
2019-03-08 13:57           ` Enrico Weigelt, metux IT consult
2019-03-08 13:57           ` lkml
2019-03-08 14:04           ` Greg KH
2019-03-08 14:04             ` Greg KH
2019-03-08 14:04             ` gregkh
2019-03-08 14:02         ` Greg KH
2019-03-08 14:02           ` Greg KH
2019-03-08 14:02           ` gregkh
2019-03-08 17:58           ` Joel Fernandes
2019-03-08 17:58             ` Joel Fernandes
2019-03-08 17:58             ` joel
2019-03-08 17:59           ` Geert Uytterhoeven
2019-03-08 17:59             ` Geert Uytterhoeven
2019-03-08 17:59             ` geert
2019-03-09  7:16             ` Greg KH
2019-03-09  7:16               ` Greg KH
2019-03-09  7:16               ` gregkh
2019-03-09 11:40               ` Geert Uytterhoeven
2019-03-09 11:40                 ` Geert Uytterhoeven
2019-03-09 11:40                 ` geert
2019-03-09 12:11                 ` Greg KH [this message]
2019-03-09 12:11                   ` Greg KH
2019-03-09 12:11                   ` gregkh
2019-03-09 16:51                   ` Karim Yaghmour
2019-03-09 16:51                     ` Karim Yaghmour
2019-03-09 16:51                     ` karim.yaghmour
2019-03-09 19:26                     ` Geert Uytterhoeven
2019-03-09 19:26                       ` Geert Uytterhoeven
2019-03-09 19:26                       ` geert
2019-03-09 21:44                       ` Karim Yaghmour
2019-03-09 21:44                         ` Karim Yaghmour
2019-03-09 21:44                         ` karim.yaghmour
2019-03-11  8:03                         ` Geert Uytterhoeven
2019-03-11  8:03                           ` Geert Uytterhoeven
2019-03-11  8:03                           ` geert
2019-03-12 15:15                           ` Karim Yaghmour
2019-03-12 15:15                             ` Karim Yaghmour
2019-03-12 15:15                             ` karim.yaghmour
2019-03-11 23:36                         ` Steven Rostedt
2019-03-11 23:36                           ` Steven Rostedt
2019-03-11 23:36                           ` rostedt
2019-03-11 23:58                           ` Daniel Colascione
2019-03-11 23:58                             ` Daniel Colascione
2019-03-11 23:58                             ` dancol
2019-03-12  0:39                             ` Joel Fernandes
2019-03-12  0:39                               ` Joel Fernandes
2019-03-12  0:39                               ` joel
2019-03-12  1:28                               ` Steven Rostedt
2019-03-12  1:28                                 ` Steven Rostedt
2019-03-12  1:28                                 ` rostedt
2019-03-12  1:38                                 ` Joel Fernandes
2019-03-12  1:38                                   ` Joel Fernandes
2019-03-12  1:38                                   ` joelaf
2019-03-13  1:18                                   ` Masami Hiramatsu
2019-03-13  1:18                                     ` Masami Hiramatsu
2019-03-13  1:18                                     ` mhiramat
2019-03-14 12:27                                     ` Joel Fernandes
2019-03-14 12:27                                       ` Joel Fernandes
2019-03-14 12:27                                       ` joel
2019-03-15 13:14                                       ` Masami Hiramatsu
2019-03-15 13:14                                         ` Masami Hiramatsu
2019-03-15 13:14                                         ` mhiramat
2019-03-12  1:45                                 ` Alexei Starovoitov
2019-03-12  1:45                                   ` Alexei Starovoitov
2019-03-12  1:45                                   ` alexei.starovoitov
2019-03-12 15:26                                   ` Steven Rostedt
2019-03-12 15:26                                     ` Steven Rostedt
2019-03-12 15:26                                     ` rostedt
2019-03-12  1:22                             ` Steven Rostedt
2019-03-12  1:22                               ` Steven Rostedt
2019-03-12  1:22                               ` rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190309121141.GA30173@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=atishp04@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dancol@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=geert@linux-m68k.org \
    --cc=groeck@chromium.org \
    --cc=joel@joelfernandes.org \
    --cc=karim.yaghmour@opersys.com \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=linux@manojrajarao.com \
    --cc=mhiramat@kernel.org \
    --cc=qais.yousef@arm.com \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.