linux-kernel - Re: [PATCH] livepatch: introduce klp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 4 Jun 2024 22:04:42 -0700
From: Song Liu <song@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Miroslav Benes <mbenes@...e.cz>, zhang warden <zhangwarden@...il.com>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Jiri Kosina <jikos@...nel.org>, 
	Joe Lawrence <joe.lawrence@...hat.com>, live-patching@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] livepatch: introduce klp_func called interface

On Tue, May 21, 2024 at 1:04 AM Petr Mladek <pmladek@...e.com> wrote:
[...]
> >
> > Yes, but the information you get is limited compared to what is available
> > now. You would obtain the information that a patched function was called
> > but ftrace could also give you the context and more.
>
> Another motivation to use ftrace for testing is that it does not
> affect the performance in production.
>
> We should keep klp_ftrace_handler() as fast as possible so that we
> could livepatch also performance sensitive functions.

At LPC last year, we discussed about adding a counter to each
klp_func, like:

struct klp_func {
    ...
    u64 __percpu counter;
    ...
};

With some static_key (+ sysctl), this should give us a way to estimate
the overhead of livepatch. If we have the counter, this patch is not
needed any more. Does this (adding the counter) sound like
something we still want to pursue?

Thanks,
Song