linux-kernel - Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules

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.1908200948260.9536@pobox.suse.cz>
Date:   Tue, 20 Aug 2019 09:54:05 +0200 (CEST)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Joe Lawrence <joe.lawrence@...hat.com>
cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        live-patching@...r.kernel.org,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch
 modules

> > How is this feature supposed to work for external modules?
> > 
> > klp-convert receives:
> > "symbols from vmlinux" + "symbols from no-klp in-tree modules"
> > + "symbols from no-klp external modules" ??
> > 
> 
> I don't think that this use-case has been previously thought out (Miroslav,
> correct me if I'm wrong here.)
> 
> I did just run an external build of a copy of
> samples/livepatch/livepatch-annotated-sample.c:
> 
>  - modules.livepatch is generated in external dir
>  - klp-convert is invoked for the livepatch module
>  - the external livepatch module successfully loads
> 
> But that was only testing external livepatch modules.
> 
> I don't know if we need/want to support general external modules supplementing
> Symbols.list, at least for the initial klp-convert commit.  I suppose external
> livepatch modules would then need to specify additional Symbols.list(s) files
> somehow as well.

I think we discussed it briefly and decided to postpone it for later 
improvements. External modules are not so important in my opinion.
 
> > 
> > BTW, 'Symbols.list' sounds like a file to list out symbols
> > for generic purposes, but in fact, the
> > file format is very specific for the klp-convert tool.
> > Perhaps, is it better to rename it so it infers
> > this is for livepatching? What do you think?
> > 
> 
> I don't know if the "Symbols.list" name and leading uppercase was based on any
> convention, but something like symbols.klp would be fine with me.

symbols.klp looks ok

Miroslav