Re: RFC: another way to make livepatch

[pizza <laokz@foxmail.com>]

On Wed, 2024-01-10 at 08:52 -0300, Marcos Paulo de Souza wrote:
> On Thu, 2023-12-21 at 22:06 +0800, laokz wrote:
> > Hi,
> > 
> > Is it off-topic talking about livepatch making tool? I tried another
> > way and
> > want to get your expert opinion if there any fatal pitfall.
> 
> I don't think it's out of scope, but what exactly you mean by "another

Thanks.

> way to make livepatch"? You would like to know about different
> approaches like source-based livepatch compared to kpatch, or you mean

Yes, exactly. Inspired by kpatch, I tried to make livepatch on source level
to avoid difficult binary hacking, just like what we did normal module
development. The main idea is similar to some topics of this mail list,

1. Write livepatch-sample.c stylish source code, put all needed non-
export/non-include symbols(I call them KLPSYMs) declarations in file.
2. Generate KLPSYMs position information through kallsyms etc.
3. `KBUILD_MODPOST_WARN=1 make` to build a "partial linked" .ko.
4. Use a klp-convert like tool to transform the KLPSYMs.

For simple patch, hand-write source might be easy though a little time
consuming. I used libclang to auto abbreviate livepatch source[1]. 

The main obstacle, IMO, is "how to determine non-included local symbols",
because they might be inlined, optimized out, duplicate names, mangled
names, and because kallsyms, vmlinux .symtab less some verbose information.
In my toy, I used DWARF along with kallsyms to try to verify all of them. 

But now I realized that DWARF might be the fatal pitfall. That's a pity. I
still get hope that's not too bad:)

[1] https://gitee.com/laokz/klpmake
[2] mirror: https://github.com/laokz/klpmake

> something different?
> 
> Thanks!
> 
> > 
> > Thanks.
> > 
> > laokz
> > 
> > 
> 
>