Re: [PATCH 0/8] unwind, arm64: add sframe unwinder for kernel

Weinan Liu <[email protected]>
Newsgroups org.kernel.vger.linux-toolchains,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.live-patching
Message-ID <[email protected]>
On Tue, Feb 25, 2025 at 11:38 AM Indu Bhagat <[email protected]> wrote:
>
> On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu <[email protected]> wrote:
> >> I already have a WIP patch to add sframe support to the kernel module.
> >> However, it is not yet working. I had trouble unwinding frames for the
> >> kernel module using the current algorithm.
> >>
> >> Indu has likely identified the issue and will be addressing it from the
> >> toolchain side.
> >>
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=32666
> >
> > I have a working in progress patch that adds sframe support for kernel
> > module.
> > https://github.com/heuza/linux/tree/sframe_unwinder.rfc
> >
> > According to the sframe table values I got during runtime testing, looks
> > like the offsets are not correct .
> >
>
> I hope to sanitize the fix for 32666 and post upstream soon (I had to
> address other related issues).  Unless fixed, relocating .sframe
> sections using the .rela.sframe is expected to generate incorrect output.
>
> > When unwind symbols init_module(0xffff80007b155048) from the kernel
> > module(livepatch-sample.ko), the start_address of the FDE entries in the
> > sframe table of the kernel modules appear incorrect.
>
> init_module will apply the relocations on the .sframe section, isnt it ?
>
> > For instance, the first FDE's start_addr is reported as -20564. Adding
> > this offset to the module's sframe section address (0xffff80007b15a040)
> > yields 0xffff80007b154fec, which is not within the livepatch-sample.ko
> > memory region(It should be larger than 0xffff80007b155000).
> >
>
> Hmm..something seems off here.  Having tested a potential fix for 32666
> locally, I do not expect the first FDE to show this symptom.
>

Yes, I think init_module will apply the relocation as well.
To further investigate, here's the relevant relocation and symbol table
information for the kernel module:

Relocation section '.rela.sframe' at offset 0x28350 contains 3 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000000001c  000100000105 R_AARCH64_PREL32  0000000000000000 .text + 8
000000000030  000100000105 R_AARCH64_PREL32  0000000000000000 .text + 28
000000000044  000100000105 R_AARCH64_PREL32  0000000000000000 .text + 68

Symbol table '.symtab' contains 68 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 .text
...
    32: 0000000000000008    12 FUNC    LOCAL  DEFAULT    1 livepatch_exit
    33: 0000000000000008     0 NOTYPE  LOCAL  DEFAULT    3 $d
    34: 0000000000000028    44 FUNC    LOCAL  DEFAULT    1 livepatch_init
    35: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    9 $d
    36: 0000000000000010     0 NOTYPE  LOCAL  DEFAULT    3 $d
    37: 0000000000000068    56 FUNC    LOCAL  DEFAULT    1 livepatch_cmdlin[...]
...
    63: 0000000000000008    12 FUNC    GLOBAL DEFAULT    1 cleanup_module
    64: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND klp_enable_patch
    65: 0000000000000028    44 FUNC    GLOBAL DEFAULT    1 init_module
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.