SUSE / libpulp

libpulp enables live patching in user space applications.
GNU Lesser General Public License v2.1
55 stars 11 forks source link

Port libpulp to ppc64le #213

Closed giulianobelinassi closed 2 weeks ago

giulianobelinassi commented 3 months ago

This PR ports libpulp to PowerPC64LE. It is broken down into two commits:

  1. Factor-out x86_64 architecture dependent code into arch/x86_64.
  2. Introduce the ppc64le equivalent code into arch/powerpc64le.

This PR requires GCC with the following patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html

dubeyabhishek commented 1 week ago

@giulianobelinassi @susematz How about the gcc patch for fpatchable-function entry? Is that upstream?

giulianobelinassi commented 1 week ago

@giulianobelinassi @susematz How about the gcc patch for fpatchable-function entry? Is that upstream?

No, the patch is not upstream yet for unknown reasons.

dubeyabhishek commented 1 week ago

@giulianobelinassi @susematz FYI. The prologue in current implementation works for patching library functions with less than 8 arguments. If the "function to be patched" is having more than 8 arguments, than referencing 8th argument onward in the patched function results in incorrect values. This happens due to auxiliary stack being created by current prologue code, which disturbs the offset referencing of parameters passed on stack by caller(8th argument onwards).

dubeyabhishek commented 1 week ago

@giulianobelinassi can you give a push for the gcc PR on bugzilla?

giulianobelinassi commented 1 week ago

@giulianobelinassi can you give a push for the gcc PR on bugzilla?

I just did it: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980

@giulianobelinassi @susematz FYI. The prologue in current implementation works for patching library functions with less than 8 arguments. If the "function to be patched" is having more than 8 arguments, than referencing 8th argument onward in the patched function results in incorrect values. This happens due to auxiliary stack being created by current prologue code, which disturbs the offset referencing of parameters passed on stack by caller(8th argument onwards).

Do you have a suggestion of how to do it without creating this stack? That can also generate a prologue code with fewer bytes, thus reducing binary size and perhaps performance issues related to it.

dubeyabhishek commented 1 week ago

I have tried couple of approaches, that I have experimented. But none of them works perfectly. Every approach is having some limitation. We need to have something like Michael Ellerman's solution to kernel live patching: https://mpe.github.io/posts/2016/05/23/kernel-live-patching-for-ppc64le/

If we can have one register dedicated to store livepatch-stack-pointer(livepatch stack can be provisioned from libpulp code at trigger time), then we can use that register to push LR/TOC value on live patch stack instead of thread stack. This approach will avoid argument issue pointed in last comment.

To have some register reserved for such kind of use, I was exploring gcc compiler options like -fcall-saved-reg. Here "reg" would be some register which is non critical during function call. If you have any input around this approach, we can discuss further.

giulianobelinassi commented 1 week ago

I just confirmed the problem with passing more than 8 parameters to a function.