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

Message-ID: <ZuLwJIgt4nsQKvqZ@redhat.com>
Date: Thu, 12 Sep 2024 09:44:04 -0400
From: Joe Lawrence <joe.lawrence@...hat.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>,
	Petr Mladek <pmladek@...e.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, Sep 11, 2024 at 12:39:42AM -0700, Josh Poimboeuf wrote:
> On Mon, Sep 02, 2024 at 08:59:43PM -0700, Josh Poimboeuf wrote:
> > Hi,
> > 
> > Here's a new way to build livepatch modules called klp-build.
> > 
> > I started working on it when I realized that objtool already does 99% of
> > the work needed for detecting function changes.
> > 
> > This is similar in concept to kpatch-build, but the implementation is
> > much cleaner.
> > 
> > Personally I still have reservations about the "source-based" approach
> > (klp-convert and friends), including the fragility and performance
> > concerns of -flive-patching.  I would submit that klp-build might be
> > considered the "official" way to make livepatch modules.
> > 
> > Please try it out and let me know what you think.  Based on v6.10.
> > 
> > Also avaiable at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git klp-build-rfc
> 
> Here's an updated branch with a bunch of fixes.  It's still incompatible
> with BTF at the moment, otherwise it should (hopefully) fix the rest of
> the issues reported so far.
> 
> While the known bugs are fixed, I haven't finished processing all the
> review comments yet.  Once that happens I'll post a proper v2.
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git klp-build-v1.5

Hi Josh,

I've had much better results with v1.5, thanks for collecting up those
fixes in a branch.

One new thing to report: depending on the optimzation of
drivers/gpu/drm/vmwgfx/vmwgfx.o, objtool may throw a complaint about an
unexpected relocation symbol type:

  $ make -j$(nproc) drivers/gpu/drm/vmwgfx/vmwgfx.o
  drivers/gpu/drm/vmwgfx/vmwgfx.o: error: objtool [check.c:1048]: unexpected relocation symbol type in .rela.discard.func_stack_frame_non_standard: 0
  
I modified check.c to print the reloc->sym->name in this case and it
reports, "vmw_recv_msg".

If I recreate vmwgfx.o and dump the symbol table, I notice that this is
a NOTYPE symbol (probably because of vmw_recv_msg.constprop.0?)

  $ ld -m elf_x86_64 -z noexecstack   -r -o drivers/gpu/drm/vmwgfx/vmwgfx.o @drivers/gpu/drm/vmwgfx/vmwgfx.mod
  $ readelf --wide --symbols drivers/gpu/drm/vmwgfx/vmwgfx.o | grep -b -e 'vmw_recv_msg' -e 'vmw_send_msg'
  148334:  2198: 0000000000000010   183 FUNC    LOCAL  DEFAULT 1255 vmw_send_msg
  151116:  2234: 0000000000000010   409 FUNC    LOCAL  DEFAULT 1251 vmw_recv_msg.constprop.0
  180895:  2615: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND vmw_recv_msg

I don't think the config matters (I used the centos-stream-10 config) as
long as the driver builds.  I only saw this with a rhel-9 gcc version
11.5.0 20240719 (Red Hat 11.5.0-2) and not fedora gcc version 12.3.1
20230508 (Red Hat 12.3.1-1), which kept vmw_recv_msg w/o constprop.

--
Joe