linux-kernel - Re: [RFC 00/31] objtool, livepatch: Livepatch module generation

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] [day] [month] [year] [list]

Message-ID: <ZukrwP5IVV8Gmoby@pathway.suse.cz>
Date: Tue, 17 Sep 2024 09:12:44 +0200
From: Petr Mladek <pmladek@...e.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, Miroslav Benes <mbenes@...e.cz>,
	Joe Lawrence <joe.lawrence@...hat.com>,
	Jiri Kosina <jikos@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Marcos Paulo de Souza <mpdesouza@...e.com>,
	Song Liu <song@...nel.org>
Subject: Re: [RFC 00/31] objtool, livepatch: Livepatch module generation

On Wed 2024-09-11 09:20:05, Josh Poimboeuf wrote:
> Hi Petr,
> 
> Thank you for trying it out and doing the research to compare it with
> kpatch-build.
> 
> On Wed, Sep 11, 2024 at 03:27:27PM +0200, Petr Mladek wrote:
> > Without -ffunction-sections -fdata-sections:
> > 
> > 	$> time make -j8
> > 	real    0m58.719s
> > 	user    3m25.925s
> > 	sys     0m21.895s
> > 
> > With -ffunction-sections -fdata-sections:
> > 
> > 	$> time make -j8
> > 	real    13m28.126s
> > 	user    15m43.944s
> > 	sys     0m29.142s
> 
> That's bad.  We should figure out where those bottlenecks are in the
> toolchain.  I know objtool definitely needs improvements there.

It looks that most of the time is spend by the linker "ld".

I have be running an incremental build which basically did only
the linking:

	$> time make -j8
	real    10m46.911s
	user    10m46.533s
	sys     0m13.062s


It has spent most of the time on the line:

	LD      vmlinux.o

I have been monitoring (very ugly way) the linker process.
The last ps output is:

	$> result=0; while test $result -eq 0 ; do ps faux | grep 16785; result="$?" ; sleep 1 ; done | grep vmlinux
	USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
	[...]
	pmladek    16785 99.6  5.2 869892 853364 pts/5   R+   16:50  10:03  |                       \_ ld -m elf_x86_64 -z noexecstack --no-warn-rwx-segments -r -o vmlinux.o --whole-archive vmlinux.a --no-whole-archive --start-group --end-group
	                                                             ^^^^^

It has been running 10:03 minutes.

> For kpatch-build, the production kernel is built *without*
> -ffunction-sections and -fdata-sections.  Then those flags get manually
> added to CLAGS by kpatch-build for the comparison builds.

It is great that it works this way. It might make sense to use these
flags only when klp-build is called.

> We rely on ccache to speed up the repeat builds during development.

I see. Well, it does not help with the linker :-(

> So I think this should be merged once the x86 support is complete, as it
> will have users immediately for those who are running on x86 with IBT
> and/or LTO.

It looks to me that many parts of this patchset do a clean up of the
objtool code. It might make sense to merge them even earlier to reduce
the size of the patchset.

Anyway, I am open to split this into more stages. Big patchsets are
always painful. And it seems that there is a big interest to get this
into a production ready state. I am not afraid of ending up with a half
baked solution.

Best Regards,
Petr