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: <20250225230137.620606-1-wnliu@google.com>
Date: Tue, 25 Feb 2025 23:01:36 +0000
From: Weinan Liu <wnliu@...gle.com>
To: jpoimboe@...nel.org
Cc: indu.bhagat@...cle.com, irogers@...gle.com, joe.lawrence@...hat.com, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-toolchains@...r.kernel.org, live-patching@...r.kernel.org, 
	mark.rutland@....com, peterz@...radead.org, puranjay@...nel.org, 
	roman.gushchin@...ux.dev, rostedt@...dmis.org, will@...nel.org, 
	wnliu@...gle.com
Subject: Re: [PATCH 0/8] unwind, arm64: add sframe unwinder for kernel

On Tue, Feb 25, 2025 at 10:13 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> On Tue, Feb 25, 2025 at 01:02:24AM +0000, Weinan Liu wrote:
> > On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu <wnliu@...gle.com> wrote:
> > > I already have a WIP patch to add sframe support to the kernel module.
> > > However, it is not yet working. I had trouble unwinding frames for the
> > > kernel module using the current algorithm.
> > >
> > > Indu has likely identified the issue and will be addressing it from the
> > > toolchain side.
> > >
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=32666
> >
> >
> > I have a working in progress patch that adds sframe support for kernel
> > module.
> > https://github.com/heuza/linux/tree/sframe_unwinder.rfc
> >
> > According to the sframe table values I got during runtime testing, looks
> > like the offsets are not correct .
> >
> > When unwind symbols init_module(0xffff80007b155048) from the kernel
> > module(livepatch-sample.ko), the start_address of the FDE entries in the
> > sframe table of the kernel modules appear incorrect.
> > For instance, the first FDE's start_addr is reported as -20564. Adding
> > this offset to the module's sframe section address (0xffff80007b15a040)
> > yields 0xffff80007b154fec, which is not within the livepatch-sample.ko
> > memory region(It should be larger than 0xffff80007b155000).
>
> I assume kpatch create-diff-object needs to copy over a subset of the
> .sframe section.  Similar to what kpatch_regenerate_orc_sections() does.


You're right that we need to process the sframe section like what
kpatch_regenerate_orc_sections() does when building livepatch by kpatch.

However, livepatch-sample.ko is not generated by kpatch. It is built
directly from samples/livepatch/livepatch-sample.c by gcc during the kernel
build


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ