Re: [PATCH v2 0/4] s390: compile relocatable kernel with/without fPIE

[Joe Lawrence <joe.lawrence@redhat.com>]

On 6/21/24 03:14, Sumanth Korikkar wrote:
> On Wed, Jun 19, 2024 at 02:23:49PM -0400, Joe Lawrence wrote:
>> On 6/19/24 13:01, Sumanth Korikkar wrote:
>>> On Tue, Jun 18, 2024 at 04:37:16PM -0400, Joe Lawrence wrote:
>>>> On Mon, Feb 19, 2024 at 02:27:30PM +0100, Sumanth Korikkar wrote:
>>>>> Hi All,
>>>>>
>>>>> This is a rebased version of Josh's patch series with a few fixups.
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=s390
>>>>>
>>>>> This introduces the capability to compile the s390 relocatable kernel
>>>>> with and without the -fPIE option.
>>>>>
>>>>> When utilizing the kpatch functionality, it is advisable to compile the
>>>>> kernel without the -fPIE option. This is particularly important if the
>>>>> kernel is built with the -ffunction-sections and -fdata-sections flags.
>>>>> The linker imposes a restriction on the number of sections (limited to
>>>>> 64k), necessitating the omission of -fPIE.
>>>>>
>>>>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622872.html
>>>>> [2] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/625986.html
>>>>>
>>>>> Gcc recently implemented an optimization [1] for loading symbols without
>>>>> explicit alignment, aligning with the IBM Z ELF ABI. This ABI mandates
>>>>> symbols to reside on a 2-byte boundary, enabling the use of the larl
>>>>> instruction. However, kernel linker scripts may still generate unaligned
>>>>> symbols. To address this, a new -munaligned-symbols option has been
>>>>> introduced [2] in recent gcc versions. This option has to be used with
>>>>> future gcc versions.
>>>>>
>>>>> Older Clang lacks support for handling unaligned symbols generated
>>>>> by kernel linker scripts when the kernel is built without -fPIE. However,
>>>>> future versions of Clang will include support for the -munaligned-symbols
>>>>> option. When the support is unavailable, compile the kernel with -fPIE
>>>>> to maintain the existing behavior.
>>>>>
>>>>> Patch 1 filters out -munaligned-symbol flag for vdso code. This is beneficial
>>>>> when compiling kernel with -fno-PIE and -munaligned-symbols combination.
>>>>>
>>>>> Patch 2 introduces the 'relocs' tool, which reads the vmlinux file and
>>>>> generates a vmlinux.relocs_64 section, containing offsets for all
>>>>> R_390_64 relocations.
>>>>>
>>>>> Patch 3 enables the compilation of a relocatable kernel with or without
>>>>> the -fPIE option. It  allows for building the relocatable kernel without
>>>>> -fPIE.  However, if compiler cannot handle unaligned symbols, the kernel
>>>>> is built with -fPIE.
>>>>>
>>>>> Patch 4 handles orphan .rela sections when kernel is built with
>>>>> -fno-PIE.
>>>>>
>>>>> kpatch tools changes:
>>>>> * -mno-pic-data-is-text-relative prevents relative addressing between
>>>>>   code and data. This is needed to avoid relocation error when klp text
>>>>>   and data are too far apart. kpatch already includes this flag.
>>>>>   However, with these changes, ARCH_KFLAGS+="-fPIC" should be added to
>>>>>   s390 kpatch tools, As -mno-pic-data-is-text-relative can be used only
>>>>>   with -fPIC. The corresponding pull request will be sent to kpatch
>>>>>   tools.
>>>>
>>>> Hi Sumanth,
>>>>
>>>> I noticed interesting compiler differences when adding -fPIC build
>>>> option and not.  The difference in resulting output can confuse
>>>> kpatch-build when it tries to verify that its reference build (with the
>>>> mentioned options, plus --ffunction-sections and -fdata-sections),
>>>> doesn't line up closely enough with the original vmlinux source (sans
>>>> all these options).
>>>
>>> Hi Joe,
>>>
>>> kpatch for s390 already uses extra compiler flag -mno-pic-data-is-text-relative
>>> inorder to prevent relative addressing between code and data. Also,
>>> includes -ffunction-sections and -fdata-sections along with it to identify
>>> modified functions and its relocations.
>>>
>>> Both the source code and modified code are built with the same
>>> options during kpatch-build (-fPIC added to
>>> -mno-pic-data-is-text-relative). kpatch-build was able to identify
>>> modified functions and its associated relocations and include these
>>> changes in the final kpatch module.
>>>
>>> May be I am missing some info: Does this deviation cause confusion to kpatch?
>>>
>>
>> Hi Sumanth,
>>
>> Yes, in the example I provided, the __mmput() function is only inlined
>> in kpatch builds, but not the builds that create the target vmlinux.
>> Here is a reproducer tarball that you can try against a local
>> create-diff-object binary:
>>
>> https://file.rdu.redhat.com/~jolawren/repro-s390x-shadow-newpid.tar.gz
>>
>> create-diff-object: ERROR: fork.ORIG.o: find_local_syms: 222: couldn't
>> find matching fork.c local symbols in vmlinux symbol table.
> 
> Hi Joe,
> 
> I tried to download the tarball and rhel config. Both are unreachable.
> Failed to resolve 'file.rdu.redhat.com' (Name or service not known)
> 
> Could you please provide alternative link to it?
> 

D'oh, I uploaded them to our internal filespace.  Try these links, they
should be visible to everyone:

https://people.redhat.com/~jolawren/kernel-s390x-rhel.config
https://people.redhat.com/~jolawren/repro-s390x-special-static.tar.gz

-- 
Joe