linux-kernel - Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal

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: <20190905123558.d4zh4h5pnej6pcuk@treble>
Date:   Thu, 5 Sep 2019 07:35:58 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Miroslav Benes <mbenes@...e.cz>
Cc:     Petr Mladek <pmladek@...e.com>,
        Joe Lawrence <joe.lawrence@...hat.com>, jikos@...nel.org,
        linux-kernel@...r.kernel.org, live-patching@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module
 removal

On Thu, Sep 05, 2019 at 02:03:34PM +0200, Miroslav Benes wrote:
> > >   + I would like to better understand the scope of the current
> > >     problems. It is about modifying code in the livepatch that
> > >     depends on position of the related code:
> > > 
> > >       + relocations are rather clear; we will need them anyway
> > > 	to access non-public (static) API from the original code.
> > > 
> > >       + What are the other changes?
> > 
> > I think the .klp.arch sections are the big ones:
> > 
> >   .klp.arch.altinstructions
> >   .klp.arch.parainstructions
> >   .klp.arch.jump_labels (doesn't exist yet)
> > 
> > And that's just x86...
> 
> I may misunderstand, but we have .klp.arch sections because para and 
> alternatives have to be processed after relocations. And if we cannot get 
> rid of relocations completely, because of static symbols, then we cannot 
> get rid of .klp.arch sections either.

With late module patching gone, the module code can just process the klp
relocations at the same time it processes normal relocations.

Then the normal module alt/para/jump_label processing code can be used
instead of arch_klp_init_object_loaded().

Note this also means that Joe's patches can remove copy_module_elf() and
free_module_elf().  And module_arch_freeing_init() in s390.

> > And then of course there's the klp coming/going notifiers which have
> > also been an additional source of complexity.
> 
> True, but I think we (me and Petr) do not consider it as much of a problem 
> as you.

It's less of an issue than .klp.arch and all the related code which can
be removed.

-- 
Josh