linux-kernel - Re: [PATCH v7 00/10] livepatch: klp-convert tool

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 for Android: free password hash cracker in your pocket

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

Message-ID: <dlivegt4sjm632m3sete73me3i2rceojfo4q4hji5ubvdcn2ly@f3tx6y5kqmkc>
Date:   Tue, 2 May 2023 20:38:01 -0300
From:   Marcos Paulo de Souza <mpdesouza@...e.de>
To:     Nicolai Stange <nstange@...e.de>
Cc:     Josh Poimboeuf <jpoimboe@...nel.org>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kbuild@...r.kernel.org, Miroslav Benes <mbenes@...e.cz>,
        Petr Mladek <pmladek@...e.com>,
        Marcos Paulo de Souza <mpdesouza@...e.com>,
        Lukas Hruska <lhruska@...e.cz>
Subject: Re: [PATCH v7 00/10] livepatch: klp-convert tool

On Tue, Apr 11, 2023 at 12:06:43PM +0200, Nicolai Stange wrote:
> Josh Poimboeuf <jpoimboe@...nel.org> writes:
> 
> > On Fri, Mar 17, 2023 at 04:29:48PM -0400, Joe Lawrence wrote:
> >> Have you tried retrofitting klp-convert into any real-world livepatch?
> >> I'm curious as to your observations on the overall experience, or
> >> thoughts on the sympos annotation style noted above.
> >
> > On a related note, the patch creation process (of which klp-convert
> > would be part of) needs to be documented.
> >
> > If I remember correctly, the proper safe usage of klp-convert requires a
> > kernel built with -flive-patching, plus some scripting and/or manual
> > processes.
> 
> Not always, I think: -flive-patching or IPA optimizations in general
> aren't a concern in the context of data symbols. From a quick glance, it
> seems like the selftests introduced as part of this patchset are
> all restricted to this usecase.

<snip>

> What do you think, does it make sense to eventually have such a bare
> minimum klp-convert merged in-tree, independently of the ongoing
> discussion around the livepatch preparation processes, respectively (the
> lack of) documentation around it? If yes, Lukas, now on CC, is
> interested in this topic and would be willing to help out in any form
> desired: either by contributing to Joe's work here or, if deemed more
> feasible, to start out completely new from scratch -- dependent on your
> opinion on the proposed, more minimal approach as well as on Joe's plans
> around klp-convert.
> 
> Looking forward to hearing your feedback!

So guys, any feedback? Ping :)

> 
> Thanks,
> 
> Nicolai
> 
> (*) We've been experimenting with building the relocation records
>     manually by various means, e.g. with GNU as' .reloc directive as an
>     example, but this all turned out impractical for various
>     reasons. Most noteworthy, because the records' offsets wouldn't get
>     adjusted properly when linking AFAIR.
> 
> (**) by some other means than directly with kpatch-build
> 
> -- 
> SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> (HRB 36809, AG Nürnberg)