On 2/7/23 07:57, Marcos Paulo de Souza wrote:
> On Wed, Feb 16, 2022 at 11:39:28AM -0500, Joe Lawrence wrote:
>> This mostly a rebase update of the livepatch klp-convert tool used to
>> generate klp-relocation types (explained in the summary below).
>>
>> I'm marking this as an RFC as it hasn't been extensively tested for all
>> livepatch supported arches. There are may be a few symbol annotation
>> changes pending what may be implemented for the FGKASLR patchset, I've
>> left a few TODO and // question? marks in the code, etc. At the same
>> time, I think "CET/IBT support and live-patches" highlighted a potential
>> need for this tooling, so I'm posting it in its current format for
>> discussion. I'll reply to individual patches to highlight a few points
>> of interest.
>>
>>
>> Summary
>> -------
>>
>> Livepatches may use symbols which are not contained in its own scope,
>> and, because of that, may end up compiled with relocations that will
>> only be resolved during module load. Yet, when the referenced symbols
>> are not exported, solving this relocation requires information on the
>> object that holds the symbol (either vmlinux or modules) and its
>> position inside the object, as an object may contain multiple symbols
>> with the same name. Providing such information must be done accordingly
>> to what is specified in Documentation/livepatch/module-elf-format.txt.
>>
>> Currently, there is no trivial way to embed the required information as
>> requested in the final livepatch elf object. klp-convert solves this
>> problem in two different forms: (i) by relying on a symbol map, which is
>> built during kernel compilation, to automatically infer the relocation
>> targeted symbol, and, when such inference is not possible (ii) by using
>> annotations in the elf object to convert the relocation accordingly to
>> the specification, enabling it to be handled by the livepatch loader.
>>
>> Given the above, add support for symbol mapping in the form of a
>> symbols.klp file; add klp-convert tool; integrate klp-convert tool into
>> kbuild; make livepatch modules discernible during kernel compilation
>> pipeline; add data-structure and macros to enable users to annotate
>> livepatch source code; make modpost stage compatible with livepatches;
>> update livepatch-sample and update documentation.
>>
>> The patch was tested under three use-cases:
>>
>> use-case 1: There is a relocation in the lp that can be automatically
>> resolved by klp-convert. For example. see the saved_command_line
>> variable in lib/livepatch/test_klp_convert2.c.
>>
>> use-case 2: There is a relocation in the lp that cannot be automatically
>> resolved, as the name of the respective symbol appears in multiple
>> objects. The livepatch contains an annotation to enable a correct
>> relocation. See the KLP_MODULE_RELOC / KLP_SYMPOS annotation sections
>> in lib/livepatch/test_klp_convert{1,2}.c.
>>
>> use-case 3: There is a relocation in the lp that cannot be automatically
>> resolved similarly as 2, but no annotation was provided in the
>> livepatch, triggering an error during compilation. Reproducible by
>> removing the KLP_MODULE_RELOC / KLP_SYMPOS annotation sections in
>> lib/livepatch/test_klp_convert{1,2}.c.
>>
>> Selftests have been added to exercise these klp-convert use-cases
>> through several tests.
>>
>>
>> Branches
>> --------
>>
>>
>> Previous versions
>> -----------------
>>
>> RFC:
>> https://lore.kernel.org/lkml/cover.1477578530.git.jpoimboe@xxxxxxxxxx/
>> v2:
>> https://lore.kernel.org/lkml/f52d29f7-7d1b-ad3d-050b-a9fa8878faf2@xxxxxxxxxx/
>> v3:
>> https://lore.kernel.org/lkml/20190410155058.9437-1-joe.lawrence@xxxxxxxxxx/
>> v4:
>> https://lore.kernel.org/lkml/20190509143859.9050-1-joe.lawrence@xxxxxxxxxx/
>> v5:
>> (not posted)
>> https://github.com/joe-lawrence/klp-convert-tree/tree/klp-convert-v5-devel
>> v6:
>> https://github.com/joe-lawrence/klp-convert-tree/tree/klp-convert-v6
>> https://github.com/joe-lawrence/klp-convert-tree/tree/klp-convert-v6-devel
>
> Hi Joe,
>
> I send reviews to some patches of the v6 batch, but there is currently a v7 in
> your github profile. I believe that I sent Rb for patches that are the same
> between versions.
>
> The current version is almost one year older already. Do you plan to send v7
> soon?
>
Hi Marcos,
Thanks for the reviews and indeed, it has been a while since v6.
For v7, I would like to rebase on top of v6.2 so it includes the recent
x86/ppc64le relocation fixes from Song/Josh.
There are still a fair number of design questions that I have.. but a
fresh version will be much easier to test and review. I'll try to get
it posted in the new few weeks.
--
Joe
