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]

Message-ID: <alpine.LSU.2.21.2406071102420.29080@pobox.suse.cz>
Date: Fri, 7 Jun 2024 11:07:36 +0200 (CEST)
From: Miroslav Benes <mbenes@...e.cz>
To: Song Liu <song@...nel.org>
cc: Petr Mladek <pmladek@...e.com>, 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

Hi,

On Tue, 4 Jun 2024, Song Liu wrote:

> 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?

It would be better than this patch but given what was mentioned in the 
thread I wonder if it is possible to use ftrace even for this. See 
/sys/kernel/tracing/trace_stat/function*. It already gathers the number of 
hits.

Would it be sufficient for you? I guess it depends on what the intention 
is. If there is no time limit, klp_func.counter might be better to provide 
some kind of overall statistics (but I am not sure if it has any value) 
and to avoid having ftrace registered on a live patched function for 
infinite period of time. If the intention is to gather data for some 
limited period, trace_stat sounds like much better approach to me.

Regards
Miroslav