Message ID | 20190426190430.172543-1-joel@joelfernandes.org (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | [v7,resend,1/2] Provide in-kernel headers to make extending kernel easier | expand |
On Fri, Apr 26, 2019 at 03:04:29PM -0400, Joel Fernandes (Google) wrote: > Introduce in-kernel headers which are made available as an archive > through proc (/proc/kheaders.tar.xz file). This archive makes it > possible to run eBPF and other tracing programs that need to extend the > kernel for tracing purposes without any dependency on the file system > having headers. > > A github PR is sent for the corresponding BCC patch at: > https://github.com/iovisor/bcc/pull/2312 > > On Android and embedded systems, it is common to switch kernels but not > have kernel headers available on the file system. Further once a > different kernel is booted, any headers stored on the file system will > no longer be useful. This is an issue even well known to distros. > By storing the headers as a compressed archive within the kernel, we can > avoid these issues that have been a hindrance for a long time. > > The best way to use this feature is by building it in. Several users > have a need for this, when they switch debug kernels, they do not want to > update the filesystem or worry about it where to store the headers on > it. However, the feature is also buildable as a module in case the user > desires it not being part of the kernel image. This makes it possible to > load and unload the headers from memory on demand. A tracing program can > load the module, do its operations, and then unload the module to save > kernel memory. The total memory needed is 3.3MB. > > By having the archive available at a fixed location independent of > filesystem dependencies and conventions, all debugging tools can > directly refer to the fixed location for the archive, without concerning > with where the headers on a typical filesystem which significantly > simplifies tooling that needs kernel headers. > > The code to read the headers is based on /proc/config.gz code and uses > the same technique to embed the headers. > > Other approaches were discussed such as having an in-memory mountable > filesystem, but that has drawbacks such as requiring an in-kernel xz > decompressor which we don't have today, and requiring usage of 42 MB of > kernel memory to host the decompressed headers at anytime. Also this > approach is simpler than such approaches. > > Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On Sat, Apr 27, 2019 at 03:38:44PM +0200, Greg KH wrote: > On Fri, Apr 26, 2019 at 03:04:29PM -0400, Joel Fernandes (Google) wrote: > > Introduce in-kernel headers which are made available as an archive > > through proc (/proc/kheaders.tar.xz file). This archive makes it > > possible to run eBPF and other tracing programs that need to extend the > > kernel for tracing purposes without any dependency on the file system > > having headers. > > > > A github PR is sent for the corresponding BCC patch at: > > https://github.com/iovisor/bcc/pull/2312 > > > > On Android and embedded systems, it is common to switch kernels but not > > have kernel headers available on the file system. Further once a > > different kernel is booted, any headers stored on the file system will > > no longer be useful. This is an issue even well known to distros. > > By storing the headers as a compressed archive within the kernel, we can > > avoid these issues that have been a hindrance for a long time. > > > > The best way to use this feature is by building it in. Several users > > have a need for this, when they switch debug kernels, they do not want to > > update the filesystem or worry about it where to store the headers on > > it. However, the feature is also buildable as a module in case the user > > desires it not being part of the kernel image. This makes it possible to > > load and unload the headers from memory on demand. A tracing program can > > load the module, do its operations, and then unload the module to save > > kernel memory. The total memory needed is 3.3MB. > > > > By having the archive available at a fixed location independent of > > filesystem dependencies and conventions, all debugging tools can > > directly refer to the fixed location for the archive, without concerning > > with where the headers on a typical filesystem which significantly > > simplifies tooling that needs kernel headers. > > > > The code to read the headers is based on /proc/config.gz code and uses > > the same technique to embed the headers. > > > > Other approaches were discussed such as having an in-memory mountable > > filesystem, but that has drawbacks such as requiring an in-kernel xz > > decompressor which we don't have today, and requiring usage of 42 MB of > > kernel memory to host the decompressed headers at anytime. Also this > > approach is simpler than such approaches. > > > > Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Thanks for the Reviewed-by tag. I believe there are still 2 logistical things to merge this. 1. Location of the header archive: Olof and Steve did not like it to be in /proc and instead /sys seemed a better choice they are Ok with. Me and Greg were Ok with it being in /sys/kernel/. Alexei, Greg and me are Ok with either proc or Sys. 2. Who is going to pull this patch: This seems a matter of where the header archive resides. If it is in /sys/kernel/ then I am assuming Greg will pull it. Masahiro has given his Reviewed-by tag, is he the one to pull it? Let us agree on these open questions so I can respin the patch to be based on that and move this forward. thanks! - Joel
On Mon, Apr 29, 2019 at 09:26:02AM -0400, Joel Fernandes wrote: > On Sat, Apr 27, 2019 at 03:38:44PM +0200, Greg KH wrote: > > On Fri, Apr 26, 2019 at 03:04:29PM -0400, Joel Fernandes (Google) wrote: > > > Introduce in-kernel headers which are made available as an archive > > > through proc (/proc/kheaders.tar.xz file). This archive makes it > > > possible to run eBPF and other tracing programs that need to extend the > > > kernel for tracing purposes without any dependency on the file system > > > having headers. > > > > > > A github PR is sent for the corresponding BCC patch at: > > > https://github.com/iovisor/bcc/pull/2312 > > > > > > On Android and embedded systems, it is common to switch kernels but not > > > have kernel headers available on the file system. Further once a > > > different kernel is booted, any headers stored on the file system will > > > no longer be useful. This is an issue even well known to distros. > > > By storing the headers as a compressed archive within the kernel, we can > > > avoid these issues that have been a hindrance for a long time. > > > > > > The best way to use this feature is by building it in. Several users > > > have a need for this, when they switch debug kernels, they do not want to > > > update the filesystem or worry about it where to store the headers on > > > it. However, the feature is also buildable as a module in case the user > > > desires it not being part of the kernel image. This makes it possible to > > > load and unload the headers from memory on demand. A tracing program can > > > load the module, do its operations, and then unload the module to save > > > kernel memory. The total memory needed is 3.3MB. > > > > > > By having the archive available at a fixed location independent of > > > filesystem dependencies and conventions, all debugging tools can > > > directly refer to the fixed location for the archive, without concerning > > > with where the headers on a typical filesystem which significantly > > > simplifies tooling that needs kernel headers. > > > > > > The code to read the headers is based on /proc/config.gz code and uses > > > the same technique to embed the headers. > > > > > > Other approaches were discussed such as having an in-memory mountable > > > filesystem, but that has drawbacks such as requiring an in-kernel xz > > > decompressor which we don't have today, and requiring usage of 42 MB of > > > kernel memory to host the decompressed headers at anytime. Also this > > > approach is simpler than such approaches. > > > > > > Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Thanks for the Reviewed-by tag. I believe there are still 2 logistical things > to merge this. > 1. Location of the header archive: > Olof and Steve did not like it to be in /proc and instead /sys seemed a better > choice they are Ok with. Me and Greg were Ok with it being in /sys/kernel/. > Alexei, Greg and me are Ok with either proc or Sys. As you say, either is fine with me. > 2. Who is going to pull this patch: This seems a matter of where the header > archive resides. If it is in /sys/kernel/ then I am assuming Greg will pull > it. Masahiro has given his Reviewed-by tag, is he the one to pull it? I can take it, but it probably should just go through the kbuild tree, as that makes more sense to me. thanks, greg k-h
On Mon, Apr 29, 2019 at 10:57 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Mon, Apr 29, 2019 at 09:26:02AM -0400, Joel Fernandes wrote: > > On Sat, Apr 27, 2019 at 03:38:44PM +0200, Greg KH wrote: > > > On Fri, Apr 26, 2019 at 03:04:29PM -0400, Joel Fernandes (Google) wrote: > > > > Introduce in-kernel headers which are made available as an archive > > > > through proc (/proc/kheaders.tar.xz file). This archive makes it > > > > possible to run eBPF and other tracing programs that need to extend the > > > > kernel for tracing purposes without any dependency on the file system > > > > having headers. > > > > > > > > A github PR is sent for the corresponding BCC patch at: > > > > https://github.com/iovisor/bcc/pull/2312 > > > > > > > > On Android and embedded systems, it is common to switch kernels but not > > > > have kernel headers available on the file system. Further once a > > > > different kernel is booted, any headers stored on the file system will > > > > no longer be useful. This is an issue even well known to distros. > > > > By storing the headers as a compressed archive within the kernel, we can > > > > avoid these issues that have been a hindrance for a long time. > > > > > > > > The best way to use this feature is by building it in. Several users > > > > have a need for this, when they switch debug kernels, they do not want to > > > > update the filesystem or worry about it where to store the headers on > > > > it. However, the feature is also buildable as a module in case the user > > > > desires it not being part of the kernel image. This makes it possible to > > > > load and unload the headers from memory on demand. A tracing program can > > > > load the module, do its operations, and then unload the module to save > > > > kernel memory. The total memory needed is 3.3MB. > > > > > > > > By having the archive available at a fixed location independent of > > > > filesystem dependencies and conventions, all debugging tools can > > > > directly refer to the fixed location for the archive, without concerning > > > > with where the headers on a typical filesystem which significantly > > > > simplifies tooling that needs kernel headers. > > > > > > > > The code to read the headers is based on /proc/config.gz code and uses > > > > the same technique to embed the headers. > > > > > > > > Other approaches were discussed such as having an in-memory mountable > > > > filesystem, but that has drawbacks such as requiring an in-kernel xz > > > > decompressor which we don't have today, and requiring usage of 42 MB of > > > > kernel memory to host the decompressed headers at anytime. Also this > > > > approach is simpler than such approaches. > > > > > > > > Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > > > > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > Thanks for the Reviewed-by tag. I believe there are still 2 logistical things > > to merge this. > > 1. Location of the header archive: > > Olof and Steve did not like it to be in /proc and instead /sys seemed a better > > choice they are Ok with. Me and Greg were Ok with it being in /sys/kernel/. > > Alexei, Greg and me are Ok with either proc or Sys. > > As you say, either is fine with me. > > > 2. Who is going to pull this patch: This seems a matter of where the header > > archive resides. If it is in /sys/kernel/ then I am assuming Greg will pull > > it. Masahiro has given his Reviewed-by tag, is he the one to pull it? > > I can take it, but it probably should just go through the kbuild tree, > as that makes more sense to me. I do not want to take responsibility for this.
On Mon, Apr 29, 2019 at 11:14:30PM +0900, Masahiro Yamada wrote: > On Mon, Apr 29, 2019 at 10:57 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Mon, Apr 29, 2019 at 09:26:02AM -0400, Joel Fernandes wrote: > > > On Sat, Apr 27, 2019 at 03:38:44PM +0200, Greg KH wrote: > > > > On Fri, Apr 26, 2019 at 03:04:29PM -0400, Joel Fernandes (Google) wrote: > > > > > Introduce in-kernel headers which are made available as an archive > > > > > through proc (/proc/kheaders.tar.xz file). This archive makes it > > > > > possible to run eBPF and other tracing programs that need to extend the > > > > > kernel for tracing purposes without any dependency on the file system > > > > > having headers. > > > > > > > > > > A github PR is sent for the corresponding BCC patch at: > > > > > https://github.com/iovisor/bcc/pull/2312 > > > > > > > > > > On Android and embedded systems, it is common to switch kernels but not > > > > > have kernel headers available on the file system. Further once a > > > > > different kernel is booted, any headers stored on the file system will > > > > > no longer be useful. This is an issue even well known to distros. > > > > > By storing the headers as a compressed archive within the kernel, we can > > > > > avoid these issues that have been a hindrance for a long time. > > > > > > > > > > The best way to use this feature is by building it in. Several users > > > > > have a need for this, when they switch debug kernels, they do not want to > > > > > update the filesystem or worry about it where to store the headers on > > > > > it. However, the feature is also buildable as a module in case the user > > > > > desires it not being part of the kernel image. This makes it possible to > > > > > load and unload the headers from memory on demand. A tracing program can > > > > > load the module, do its operations, and then unload the module to save > > > > > kernel memory. The total memory needed is 3.3MB. > > > > > > > > > > By having the archive available at a fixed location independent of > > > > > filesystem dependencies and conventions, all debugging tools can > > > > > directly refer to the fixed location for the archive, without concerning > > > > > with where the headers on a typical filesystem which significantly > > > > > simplifies tooling that needs kernel headers. > > > > > > > > > > The code to read the headers is based on /proc/config.gz code and uses > > > > > the same technique to embed the headers. > > > > > > > > > > Other approaches were discussed such as having an in-memory mountable > > > > > filesystem, but that has drawbacks such as requiring an in-kernel xz > > > > > decompressor which we don't have today, and requiring usage of 42 MB of > > > > > kernel memory to host the decompressed headers at anytime. Also this > > > > > approach is simpler than such approaches. > > > > > > > > > > Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > > > > > > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > Thanks for the Reviewed-by tag. I believe there are still 2 logistical things > > > to merge this. > > > 1. Location of the header archive: > > > Olof and Steve did not like it to be in /proc and instead /sys seemed a better > > > choice they are Ok with. Me and Greg were Ok with it being in /sys/kernel/. > > > Alexei, Greg and me are Ok with either proc or Sys. > > > > As you say, either is fine with me. > > > > > 2. Who is going to pull this patch: This seems a matter of where the header > > > archive resides. If it is in /sys/kernel/ then I am assuming Greg will pull > > > it. Masahiro has given his Reviewed-by tag, is he the one to pull it? > > > > I can take it, but it probably should just go through the kbuild tree, > > as that makes more sense to me. > > > I do not want to take responsibility for this. Hah, ok, I'll be glad to queue this up in my tree. I'll take it now, and if people who really object to this being in /proc/ and want it in /sys/, we can add a follow-on patch before 5.2-final is out to move the file to that location. thanks, greg k-h
On Mon, Apr 29, 2019 at 04:24:25PM +0200, Greg KH wrote: > On Mon, Apr 29, 2019 at 11:14:30PM +0900, Masahiro Yamada wrote: > > On Mon, Apr 29, 2019 at 10:57 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > > On Mon, Apr 29, 2019 at 09:26:02AM -0400, Joel Fernandes wrote: > > > > On Sat, Apr 27, 2019 at 03:38:44PM +0200, Greg KH wrote: > > > > > On Fri, Apr 26, 2019 at 03:04:29PM -0400, Joel Fernandes (Google) wrote: > > > > > > Introduce in-kernel headers which are made available as an archive > > > > > > through proc (/proc/kheaders.tar.xz file). This archive makes it > > > > > > possible to run eBPF and other tracing programs that need to extend the > > > > > > kernel for tracing purposes without any dependency on the file system > > > > > > having headers. > > > > > > > > > > > > A github PR is sent for the corresponding BCC patch at: > > > > > > https://github.com/iovisor/bcc/pull/2312 > > > > > > > > > > > > On Android and embedded systems, it is common to switch kernels but not > > > > > > have kernel headers available on the file system. Further once a > > > > > > different kernel is booted, any headers stored on the file system will > > > > > > no longer be useful. This is an issue even well known to distros. > > > > > > By storing the headers as a compressed archive within the kernel, we can > > > > > > avoid these issues that have been a hindrance for a long time. > > > > > > > > > > > > The best way to use this feature is by building it in. Several users > > > > > > have a need for this, when they switch debug kernels, they do not want to > > > > > > update the filesystem or worry about it where to store the headers on > > > > > > it. However, the feature is also buildable as a module in case the user > > > > > > desires it not being part of the kernel image. This makes it possible to > > > > > > load and unload the headers from memory on demand. A tracing program can > > > > > > load the module, do its operations, and then unload the module to save > > > > > > kernel memory. The total memory needed is 3.3MB. > > > > > > > > > > > > By having the archive available at a fixed location independent of > > > > > > filesystem dependencies and conventions, all debugging tools can > > > > > > directly refer to the fixed location for the archive, without concerning > > > > > > with where the headers on a typical filesystem which significantly > > > > > > simplifies tooling that needs kernel headers. > > > > > > > > > > > > The code to read the headers is based on /proc/config.gz code and uses > > > > > > the same technique to embed the headers. > > > > > > > > > > > > Other approaches were discussed such as having an in-memory mountable > > > > > > filesystem, but that has drawbacks such as requiring an in-kernel xz > > > > > > decompressor which we don't have today, and requiring usage of 42 MB of > > > > > > kernel memory to host the decompressed headers at anytime. Also this > > > > > > approach is simpler than such approaches. > > > > > > > > > > > > Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > > > > > > > > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > Thanks for the Reviewed-by tag. I believe there are still 2 logistical things > > > > to merge this. > > > > 1. Location of the header archive: > > > > Olof and Steve did not like it to be in /proc and instead /sys seemed a better > > > > choice they are Ok with. Me and Greg were Ok with it being in /sys/kernel/. > > > > Alexei, Greg and me are Ok with either proc or Sys. > > > > > > As you say, either is fine with me. > > > > > > > 2. Who is going to pull this patch: This seems a matter of where the header > > > > archive resides. If it is in /sys/kernel/ then I am assuming Greg will pull > > > > it. Masahiro has given his Reviewed-by tag, is he the one to pull it? > > > > > > I can take it, but it probably should just go through the kbuild tree, > > > as that makes more sense to me. > > > > > > I do not want to take responsibility for this. > > Hah, ok, I'll be glad to queue this up in my tree. I'll take it now, > and if people who really object to this being in /proc/ and want it in > /sys/, we can add a follow-on patch before 5.2-final is out to move the > file to that location. Sounds great to me. thanks! - Joel
> > > As you say, either is fine with me. > > > > > > > 2. Who is going to pull this patch: This seems a matter of where the header > > > > archive resides. If it is in /sys/kernel/ then I am assuming Greg will pull > > > > it. Masahiro has given his Reviewed-by tag, is he the one to pull it? > > > > > > I can take it, but it probably should just go through the kbuild tree, > > > as that makes more sense to me. > > > > > > I do not want to take responsibility for this. > > Hah, ok, I'll be glad to queue this up in my tree. I'll take it now, > and if people who really object to this being in /proc/ and want it in > /sys/, we can add a follow-on patch before 5.2-final is out to move the > file to that location. People really object to having it in kernel in the first place. Pavel
On Fri, May 03, 2019 at 09:30:07AM +0200, Pavel Machek wrote: > > > > As you say, either is fine with me. > > > > > > > > > 2. Who is going to pull this patch: This seems a matter of where the header > > > > > archive resides. If it is in /sys/kernel/ then I am assuming Greg will pull > > > > > it. Masahiro has given his Reviewed-by tag, is he the one to pull it? > > > > > > > > I can take it, but it probably should just go through the kbuild tree, > > > > as that makes more sense to me. > > > > > > > > > I do not want to take responsibility for this. > > > > Hah, ok, I'll be glad to queue this up in my tree. I'll take it now, > > and if people who really object to this being in /proc/ and want it in > > /sys/, we can add a follow-on patch before 5.2-final is out to move the > > file to that location. > > People really object to having it in kernel in the first place. Then do not select that .config option, and all is good :)
On Mon, 29 Apr 2019 16:24:25 +0200 Greg KH <gregkh@linuxfoundation.org> wrote: > Hah, ok, I'll be glad to queue this up in my tree. I'll take it now, > and if people who really object to this being in /proc/ and want it in > /sys/, we can add a follow-on patch before 5.2-final is out to move the > file to that location. I really don't think putting it in /proc now is a good idea. Let's put it in /sys now. If we don't do it now and it gets into a main release, then that will become the permanent location for it. -- Steve
On Fri, May 03, 2019 at 10:33:15AM -0400, Steven Rostedt wrote: > On Mon, 29 Apr 2019 16:24:25 +0200 > Greg KH <gregkh@linuxfoundation.org> wrote: > > > Hah, ok, I'll be glad to queue this up in my tree. I'll take it now, > > and if people who really object to this being in /proc/ and want it in > > /sys/, we can add a follow-on patch before 5.2-final is out to move the > > file to that location. > > I really don't think putting it in /proc now is a good idea. Let's put > it in /sys now. If we don't do it now and it gets into a main release, > then that will become the permanent location for it. I will send a patch to move it into /sys/kernel on top of this. Hope everyone else is also Ok with that as the location. thanks, - Joel
diff --git a/init/Kconfig b/init/Kconfig index 4592bf7997c0..47c0db6e63a5 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -580,6 +580,16 @@ config IKCONFIG_PROC This option enables access to the kernel configuration file through /proc/config.gz. +config IKHEADERS_PROC + tristate "Enable kernel header artifacts through /proc/kheaders.tar.xz" + depends on PROC_FS + help + This option enables access to the kernel header and other artifacts that + are generated during the build process. These can be used to build eBPF + tracing programs, or similar programs. If you build the headers as a + module, a module called kheaders.ko is built which can be loaded on-demand + to get access to the headers. + config LOG_BUF_SHIFT int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" range 12 25 diff --git a/kernel/.gitignore b/kernel/.gitignore index 6e699100872f..34d1e77ee9df 100644 --- a/kernel/.gitignore +++ b/kernel/.gitignore @@ -1,5 +1,6 @@ # # Generated files # +kheaders.md5 timeconst.h hz.bc diff --git a/kernel/Makefile b/kernel/Makefile index 6c57e78817da..12399614c350 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -70,6 +70,7 @@ obj-$(CONFIG_UTS_NS) += utsname.o obj-$(CONFIG_USER_NS) += user_namespace.o obj-$(CONFIG_PID_NS) += pid_namespace.o obj-$(CONFIG_IKCONFIG) += configs.o +obj-$(CONFIG_IKHEADERS_PROC) += kheaders.o obj-$(CONFIG_SMP) += stop_machine.o obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o obj-$(CONFIG_AUDIT) += audit.o auditfilter.o @@ -121,3 +122,12 @@ $(obj)/configs.o: $(obj)/config_data.gz targets += config_data.gz $(obj)/config_data.gz: $(KCONFIG_CONFIG) FORCE $(call if_changed,gzip) + +$(obj)/kheaders.o: $(obj)/kheaders_data.tar.xz + +quiet_cmd_genikh = CHK $(obj)/kheaders_data.tar.xz +cmd_genikh = $(srctree)/kernel/gen_ikh_data.sh $@ +$(obj)/kheaders_data.tar.xz: FORCE + $(call cmd,genikh) + +clean-files := kheaders_data.tar.xz kheaders.md5 diff --git a/kernel/gen_ikh_data.sh b/kernel/gen_ikh_data.sh new file mode 100755 index 000000000000..591a94f7b387 --- /dev/null +++ b/kernel/gen_ikh_data.sh @@ -0,0 +1,89 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-2.0 + +# This script generates an archive consisting of kernel headers +# for CONFIG_IKHEADERS_PROC. +set -e +spath="$(dirname "$(readlink -f "$0")")" +kroot="$spath/.." +outdir="$(pwd)" +tarfile=$1 +cpio_dir=$outdir/$tarfile.tmp + +# Script filename relative to the kernel source root +# We add it to the archive because it is small and any changes +# to this script will also cause a rebuild of the archive. +sfile="$(realpath --relative-to $kroot "$(readlink -f "$0")")" + +src_file_list=" +include/ +arch/$SRCARCH/include/ +$sfile +" + +obj_file_list=" +include/ +arch/$SRCARCH/include/ +" + +# Support incremental builds by skipping archive generation +# if timestamps of files being archived are not changed. + +# This block is useful for debugging the incremental builds. +# Uncomment it for debugging. +# iter=1 +# if [ ! -f /tmp/iter ]; then echo 1 > /tmp/iter; +# else; iter=$(($(cat /tmp/iter) + 1)); fi +# find $src_file_list -type f | xargs ls -lR > /tmp/src-ls-$iter +# find $obj_file_list -type f | xargs ls -lR > /tmp/obj-ls-$iter + +# include/generated/compile.h is ignored because it is touched even when none +# of the source files changed. This causes pointless regeneration, so let us +# ignore them for md5 calculation. +pushd $kroot > /dev/null +src_files_md5="$(find $src_file_list -type f | + grep -v "include/generated/compile.h" | + xargs ls -lR | md5sum | cut -d ' ' -f1)" +popd > /dev/null +obj_files_md5="$(find $obj_file_list -type f | + grep -v "include/generated/compile.h" | + xargs ls -lR | md5sum | cut -d ' ' -f1)" + +if [ -f $tarfile ]; then tarfile_md5="$(md5sum $tarfile | cut -d ' ' -f1)"; fi +if [ -f kernel/kheaders.md5 ] && + [ "$(cat kernel/kheaders.md5|head -1)" == "$src_files_md5" ] && + [ "$(cat kernel/kheaders.md5|head -2|tail -1)" == "$obj_files_md5" ] && + [ "$(cat kernel/kheaders.md5|tail -1)" == "$tarfile_md5" ]; then + exit +fi + +if [ "${quiet}" != "silent_" ]; then + echo " GEN $tarfile" +fi + +rm -rf $cpio_dir +mkdir $cpio_dir + +pushd $kroot > /dev/null +for f in $src_file_list; + do find "$f" ! -name "*.cmd" ! -name ".*"; +done | cpio --quiet -pd $cpio_dir +popd > /dev/null + +# The second CPIO can complain if files already exist which can +# happen with out of tree builds. Just silence CPIO for now. +for f in $obj_file_list; + do find "$f" ! -name "*.cmd" ! -name ".*"; +done | cpio --quiet -pd $cpio_dir >/dev/null 2>&1 + +# Remove comments except SDPX lines +find $cpio_dir -type f -print0 | + xargs -0 -P8 -n1 perl -pi -e 'BEGIN {undef $/;}; s/\/\*((?!SPDX).)*?\*\///smg;' + +tar -Jcf $tarfile -C $cpio_dir/ . > /dev/null + +echo "$src_files_md5" > kernel/kheaders.md5 +echo "$obj_files_md5" >> kernel/kheaders.md5 +echo "$(md5sum $tarfile | cut -d ' ' -f1)" >> kernel/kheaders.md5 + +rm -rf $cpio_dir diff --git a/kernel/kheaders.c b/kernel/kheaders.c new file mode 100644 index 000000000000..70ae6052920d --- /dev/null +++ b/kernel/kheaders.c @@ -0,0 +1,74 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Provide kernel headers useful to build tracing programs + * such as for running eBPF tracing tools. + * + * (Borrowed code from kernel/configs.c) + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/proc_fs.h> +#include <linux/init.h> +#include <linux/uaccess.h> + +/* + * Define kernel_headers_data and kernel_headers_data_end, within which the + * compressed kernel headers are stored. The file is first compressed with xz. + */ + +asm ( +" .pushsection .rodata, \"a\" \n" +" .global kernel_headers_data \n" +"kernel_headers_data: \n" +" .incbin \"kernel/kheaders_data.tar.xz\" \n" +" .global kernel_headers_data_end \n" +"kernel_headers_data_end: \n" +" .popsection \n" +); + +extern char kernel_headers_data; +extern char kernel_headers_data_end; + +static ssize_t +ikheaders_read_current(struct file *file, char __user *buf, + size_t len, loff_t *offset) +{ + return simple_read_from_buffer(buf, len, offset, + &kernel_headers_data, + &kernel_headers_data_end - + &kernel_headers_data); +} + +static const struct file_operations ikheaders_file_ops = { + .read = ikheaders_read_current, + .llseek = default_llseek, +}; + +static int __init ikheaders_init(void) +{ + struct proc_dir_entry *entry; + + /* create the current headers file */ + entry = proc_create("kheaders.tar.xz", S_IRUGO, NULL, + &ikheaders_file_ops); + if (!entry) + return -ENOMEM; + + proc_set_size(entry, + &kernel_headers_data_end - + &kernel_headers_data); + return 0; +} + +static void __exit ikheaders_cleanup(void) +{ + remove_proc_entry("kheaders.tar.xz", NULL); +} + +module_init(ikheaders_init); +module_exit(ikheaders_cleanup); + +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Joel Fernandes"); +MODULE_DESCRIPTION("Echo the kernel header artifacts used to build the kernel");