From: Joao Moreira <[email protected]>
For automatic resolution of livepatch relocations, a file called
symbols.klp is used. This file maps symbols within every compiled kernel
object allowing the identification of symbols whose name is unique, thus
relocation can be automatically inferred, or providing information that
helps developers when code annotation is required for solving the
matter.
Add support for creating symbols.klp in the main Makefile. First, ensure
that built-in is compiled when CONFIG_LIVEPATCH is enabled (as required
to achieve a complete symbols.klp file). Define the command to build
symbols.klp (cmd_klp_map) and hook it in the modules rule.
As it is undesirable to have symbols from livepatch objects inside
symbols.klp, make livepatches discernible by modifying
scripts/Makefile.build to create a .livepatch file for each livepatch in
$(MODVERDIR). This file then used by cmd_klp_map to identify and bypass
livepatches.
For identifying livepatches during the build process, a flag variable
LIVEPATCH_$(basetarget).o is considered in scripts/Makefile.build. This
way, set this flag for the livepatch sample Makefile in
samples/livepatch/Makefile.
Finally, Add a clean rule to ensure that symbols.klp is removed during
clean.
Notes:
To achieve a correct symbols.klp file, all kernel objects must be
considered, thus, its construction require these objects to be priorly
built. On the other hand, invoking scripts/Makefile.modpost without
having a complete symbols.klp in place would occasionally lead to
in-tree livepatches being post-processed incorrectly. To prevent this
from becoming a circular dependency, the construction of symbols.klp
uses non-post-processed kernel objects and such does not cause harm as
the symbols normally referenced from within livepatches are visible at
this stage. Also due to these requirements, the spot in-between modules
compilation and the invocation of scripts/Makefile.modpost was picked
for hooking cmd_klp_map.
The approach based on .livepatch files was proposed as an alternative to
using MODULE_INFO statements. This approach was originally proposed by
Miroslav Benes as a workaround for identifying livepathes without
depending on modinfo during the modpost stage. It was moved to this
patch as the approach also shown to be useful while building
symbols.klp.
Signed-off-by: Joao Moreira <[email protected]>
Signed-off-by: Joe Lawrence <[email protected]>
---
.gitignore | 1 +
Documentation/dontdiff | 1 +
Makefile | 24 ++++++++++++++++++++++--
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7afd412dadd2..50638a15a527 100644
--- a/.gitignore
+++ b/.gitignore
@@ -61,6 +61,7 @@ modules.order
/vmlinux.symvers
/vmlinux-gdb.py
/vmlinuz
+/symbols.klp
/System.map
/Module.markers
/modules.builtin
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 910b30a2a7d9..25c656fdd99f 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -76,6 +76,7 @@ Module.markers
Module.symvers
PENDING
SCCS
+symbols.klp
System.map*
TAGS
aconf
diff --git a/Makefile b/Makefile
index 0fb4f94a6885..64ec4bc8172c 100644
--- a/Makefile
+++ b/Makefile
@@ -639,8 +639,13 @@ KBUILD_MODULES :=
KBUILD_BUILTIN := 1
# If we have only "make modules", don't compile built-in objects.
+# When we're building livepatch modules, we need to consider the
+# built-in objects during the descend as well, as built-in objects may
+# hold symbols which are referenced from livepatches and are required by
+# klp-convert post-processing tool for resolving these cases.
+
ifeq ($(MAKECMDGOALS),modules)
- KBUILD_BUILTIN :=
+ KBUILD_BUILTIN := $(if $(CONFIG_LIVEPATCH),1)
endif
# If we have "make <whatever> modules", compile modules
@@ -1487,7 +1492,7 @@ MRPROPER_FILES += include/config include/generated \
arch/$(SRCARCH)/include/generated .tmp_objdiff \
debian snap tar-install \
.config .config.old .version \
- Module.symvers \
+ Module.symvers symbols.klp \
certs/signing_key.pem \
certs/x509.genkey \
vmlinux-gdb.py \
@@ -1742,7 +1747,22 @@ PHONY += modules modules_install
ifdef CONFIG_MODULES
+quiet_cmd_klp_map = KLP symbols.klp
+
+define cmd_klp_map
+ $(shell echo "klp-convert-symbol-data.0.1" > $(objtree)/symbols.klp) \
+ $(shell echo "*vmlinux" >> $(objtree)/symbols.klp) \
+ $(shell nm -f posix $(objtree)/vmlinux | cut -d\ -f1 >> $(objtree)/symbols.klp) \
+ $(foreach ko, $(sort $(shell cat modules.order)), \
+ $(eval mod = $(patsubst %.ko,%.mod,$(ko))) \
+ $(eval obj = $(patsubst %.ko,%.o,$(ko))) \
+ $(if $(shell grep -o LIVEPATCH $(mod)),, \
+ $(shell echo "*$(shell basename -s .ko $(ko))" >> $(objtree)/symbols.klp) \
+ $(shell nm -f posix $(obj) | cut -d\ -f1 >> $(objtree)/symbols.klp)))
+endef
+
modules: modules_check
+ $(if $(CONFIG_LIVEPATCH), $(call cmd,klp_map))
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
PHONY += modules_check
--
2.26.3
On Wed 2022-02-16 11:39:30, Joe Lawrence wrote:
> From: Joao Moreira <[email protected]>
>
> For automatic resolution of livepatch relocations, a file called
> symbols.klp is used. This file maps symbols within every compiled kernel
> object allowing the identification of symbols whose name is unique, thus
> relocation can be automatically inferred, or providing information that
> helps developers when code annotation is required for solving the
> matter.
>
> Add support for creating symbols.klp in the main Makefile. First, ensure
> that built-in is compiled when CONFIG_LIVEPATCH is enabled (as required
> to achieve a complete symbols.klp file). Define the command to build
> symbols.klp (cmd_klp_map) and hook it in the modules rule.
>
> As it is undesirable to have symbols from livepatch objects inside
> symbols.klp, make livepatches discernible by modifying
> scripts/Makefile.build to create a .livepatch file for each livepatch in
> $(MODVERDIR). This file then used by cmd_klp_map to identify and bypass
> livepatches.
>
> For identifying livepatches during the build process, a flag variable
> LIVEPATCH_$(basetarget).o is considered in scripts/Makefile.build. This
> way, set this flag for the livepatch sample Makefile in
> samples/livepatch/Makefile.
I do not see the related code in scripts/Makefile.build.
> Finally, Add a clean rule to ensure that symbols.klp is removed during
> clean.
>
> Notes:
>
> To achieve a correct symbols.klp file, all kernel objects must be
> considered, thus, its construction require these objects to be priorly
> built. On the other hand, invoking scripts/Makefile.modpost without
> having a complete symbols.klp in place would occasionally lead to
> in-tree livepatches being post-processed incorrectly.
Honestly, I do not understand what it exactly means that "in-tree
livepatches would occasionally be post-processed incorrectly".
Is it the problem that modpost is not able to handle the unresolved
symbols that have to be updated by klp-convert?
> To prevent this
> from becoming a circular dependency, the construction of symbols.klp
> uses non-post-processed kernel objects and such does not cause harm as
> the symbols normally referenced from within livepatches are visible at
> this stage. Also due to these requirements, the spot in-between modules
> compilation and the invocation of scripts/Makefile.modpost was picked
> for hooking cmd_klp_map.
>
> The approach based on .livepatch files was proposed as an alternative to
> using MODULE_INFO statements. This approach was originally proposed by
> Miroslav Benes as a workaround for identifying livepathes without
> depending on modinfo during the modpost stage. It was moved to this
> patch as the approach also shown to be useful while building
> symbols.klp.
All the tricky code is removed in the 5th patch. My understanding is
that the problem causing the cyclic dependency is solved by modifying
modpost.
It looks like this patch is outdated and mostly obsoleted. On the
other hand, the commit message in 5th patch is too short.
What about merging the two patches and updating the commit message?
Best Regards,
Petr
On Thu, Apr 14, 2022 at 11:35:42AM +0200 Petr Mladek wrote:
> On Wed 2022-02-16 11:39:30, Joe Lawrence wrote:
> > From: Joao Moreira <[email protected]>
> >
> > For automatic resolution of livepatch relocations, a file called
> > symbols.klp is used. This file maps symbols within every compiled kernel
> > object allowing the identification of symbols whose name is unique, thus
> > relocation can be automatically inferred, or providing information that
> > helps developers when code annotation is required for solving the
> > matter.
> >
> > Add support for creating symbols.klp in the main Makefile. First, ensure
> > that built-in is compiled when CONFIG_LIVEPATCH is enabled (as required
> > to achieve a complete symbols.klp file). Define the command to build
> > symbols.klp (cmd_klp_map) and hook it in the modules rule.
> >
> > As it is undesirable to have symbols from livepatch objects inside
> > symbols.klp, make livepatches discernible by modifying
> > scripts/Makefile.build to create a .livepatch file for each livepatch in
> > $(MODVERDIR). This file then used by cmd_klp_map to identify and bypass
> > livepatches.
> >
> > For identifying livepatches during the build process, a flag variable
> > LIVEPATCH_$(basetarget).o is considered in scripts/Makefile.build. This
> > way, set this flag for the livepatch sample Makefile in
> > samples/livepatch/Makefile.
>
> I do not see the related code in scripts/Makefile.build.
>
> > Finally, Add a clean rule to ensure that symbols.klp is removed during
> > clean.
> >
> > Notes:
> >
> > To achieve a correct symbols.klp file, all kernel objects must be
> > considered, thus, its construction require these objects to be priorly
> > built. On the other hand, invoking scripts/Makefile.modpost without
> > having a complete symbols.klp in place would occasionally lead to
> > in-tree livepatches being post-processed incorrectly.
>
> Honestly, I do not understand what it exactly means that "in-tree
> livepatches would occasionally be post-processed incorrectly".
>
> Is it the problem that modpost is not able to handle the unresolved
> symbols that have to be updated by klp-convert?
>
> > To prevent this
> > from becoming a circular dependency, the construction of symbols.klp
> > uses non-post-processed kernel objects and such does not cause harm as
> > the symbols normally referenced from within livepatches are visible at
> > this stage. Also due to these requirements, the spot in-between modules
> > compilation and the invocation of scripts/Makefile.modpost was picked
> > for hooking cmd_klp_map.
> >
> > The approach based on .livepatch files was proposed as an alternative to
> > using MODULE_INFO statements. This approach was originally proposed by
> > Miroslav Benes as a workaround for identifying livepathes without
> > depending on modinfo during the modpost stage. It was moved to this
> > patch as the approach also shown to be useful while building
> > symbols.klp.
>
> All the tricky code is removed in the 5th patch. My understanding is
> that the problem causing the cyclic dependency is solved by modifying
> modpost.
>
> It looks like this patch is outdated and mostly obsoleted. On the
> other hand, the commit message in 5th patch is too short.
>
> What about merging the two patches and updating the commit message?
+1
Yes, please merge those patches. These '$(shell ...)' side-effect lines in the
definition of 'cmd_klp_map' are quite confusing.
Kind regards,
Nicolas
On Thu, Apr 14, 2022 at 07:59:57PM +0200, Nicolas Schier wrote:
> On Thu, Apr 14, 2022 at 11:35:42AM +0200 Petr Mladek wrote:
> > On Wed 2022-02-16 11:39:30, Joe Lawrence wrote:
> > > From: Joao Moreira <[email protected]>
> > >
> > > For automatic resolution of livepatch relocations, a file called
> > > symbols.klp is used. This file maps symbols within every compiled kernel
> > > object allowing the identification of symbols whose name is unique, thus
> > > relocation can be automatically inferred, or providing information that
> > > helps developers when code annotation is required for solving the
> > > matter.
> > >
> > > Add support for creating symbols.klp in the main Makefile. First, ensure
> > > that built-in is compiled when CONFIG_LIVEPATCH is enabled (as required
> > > to achieve a complete symbols.klp file). Define the command to build
> > > symbols.klp (cmd_klp_map) and hook it in the modules rule.
> > >
> > > As it is undesirable to have symbols from livepatch objects inside
> > > symbols.klp, make livepatches discernible by modifying
> > > scripts/Makefile.build to create a .livepatch file for each livepatch in
> > > $(MODVERDIR). This file then used by cmd_klp_map to identify and bypass
> > > livepatches.
> > >
> > > For identifying livepatches during the build process, a flag variable
> > > LIVEPATCH_$(basetarget).o is considered in scripts/Makefile.build. This
> > > way, set this flag for the livepatch sample Makefile in
> > > samples/livepatch/Makefile.
> >
> > I do not see the related code in scripts/Makefile.build.
> >
> > > Finally, Add a clean rule to ensure that symbols.klp is removed during
> > > clean.
> > >
> > > Notes:
> > >
> > > To achieve a correct symbols.klp file, all kernel objects must be
> > > considered, thus, its construction require these objects to be priorly
> > > built. On the other hand, invoking scripts/Makefile.modpost without
> > > having a complete symbols.klp in place would occasionally lead to
> > > in-tree livepatches being post-processed incorrectly.
> >
> > Honestly, I do not understand what it exactly means that "in-tree
> > livepatches would occasionally be post-processed incorrectly".
> >
> > Is it the problem that modpost is not able to handle the unresolved
> > symbols that have to be updated by klp-convert?
> >
> > > To prevent this
> > > from becoming a circular dependency, the construction of symbols.klp
> > > uses non-post-processed kernel objects and such does not cause harm as
> > > the symbols normally referenced from within livepatches are visible at
> > > this stage. Also due to these requirements, the spot in-between modules
> > > compilation and the invocation of scripts/Makefile.modpost was picked
> > > for hooking cmd_klp_map.
> > >
> > > The approach based on .livepatch files was proposed as an alternative to
> > > using MODULE_INFO statements. This approach was originally proposed by
> > > Miroslav Benes as a workaround for identifying livepathes without
> > > depending on modinfo during the modpost stage. It was moved to this
> > > patch as the approach also shown to be useful while building
> > > symbols.klp.
> >
> > All the tricky code is removed in the 5th patch. My understanding is
> > that the problem causing the cyclic dependency is solved by modifying
> > modpost.
> >
> > It looks like this patch is outdated and mostly obsoleted. On the
> > other hand, the commit message in 5th patch is too short.
> >
> > What about merging the two patches and updating the commit message?
>
> +1
>
> Yes, please merge those patches. These '$(shell ...)' side-effect lines in the
> definition of 'cmd_klp_map' are quite confusing.
>
Sure. Admittedly the kbuild integration is most confusing to me, so I
leaned heavily on Joao's original notes and Masahiro's gracious tips and
refactored code. I'll try cutting to the final version in later patches
rather than providing all the (confusing) code evolution along the way.
Thanks,
-- Joe