From: Torsten Duwe <duwe@lst.de> To: Mark Rutland <mark.rutland@arm.com> Cc: Jiri Kosina <jikos@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Julien Thierry <julien.thierry@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>, AKASHI Takahiro <takahiro.akashi@linaro.org>, Ingo Molnar <mingo@redhat.com>, Ruslan Bilovol <ruslan.bilovol@gmail.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Amit Daniel Kachhap <amit.kachhap@arm.com>, live-patching@vger.kernel.org, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v8 0/5] arm64: ftrace with regs Date: Sat, 19 Oct 2019 13:01:35 +0200 [thread overview] Message-ID: <20191019130135.10de9324@blackhole.lan> (raw) In-Reply-To: <20191018174100.GC18838@lakrids.cambridge.arm.com> Hi Mark! On Fri, 18 Oct 2019 18:41:02 +0100 Mark Rutland <mark.rutland@arm.com> wrote: > In the process of reworking this I spotted some issues that will get > in the way of livepatching. Notably: > > * When modules can be loaded far away from the kernel, we'll > potentially need a PLT for each function within a module, if each can > be patched to a unique function. Currently we have a fixed number, > which is only sufficient for the two ftrace entry trampolines. > > IIUC, the new code being patched in is itself a module, in which > case we'd need a PLT for each function in the main kernel image. When no live patching is involved, obviously all cases need to have been handled so far. And when a live patching module comes in, there are calls in and out of the new patch code: Calls going into the live patch are not aware of this. They are caught by an active ftrace intercept, and the actual call into the LP module is done in klp_arch_set_pc, by manipulating the intercept (call site) return address (in case thread lives in the "new world", for completeness' sake). This is an unsigned long write in C. All calls going _out_ from the KLP module are newly generated, as part of the KLP module building process, and are thus aware of them being "extern" -- a PLT entry should be generated and accounted for in the KLP module. > We have a few options here, e.g. changing which memory size model we > use, or reserving space for a PLT before each function using > -f patchable-function-entry=N,M. Nonetheless I'm happy I once added the ,M option here. You never know :) > * There are windows where backtracing will miss the callsite's caller, > as its address is not live in the LR or existing chain of frame > records. Thus we cannot claim to have a reliable stacktrace. > > I suspect we'll have to teach the stacktrace code to handle this as > a special-case. Yes, that's where I had to step back. The unwinder needs to stop where the chain is even questionable. In _all_ cases. Missing only one race condition means a lurking inconsistency. OTOH it's not a problem to report "not reliable" when in doubt; the thread in question will then get woken up and unwind itself. It is only an optimisation to let all kernel threads which are guaranteed to not contain any patched functions sleep on. > I'll try to write these up, as similar probably applies to other > architectures with a link register. I thought I'd quickly give you my feedback upfront here. Torsten
WARNING: multiple messages have this Message-ID (diff)
From: Torsten Duwe <duwe@lst.de> To: Mark Rutland <mark.rutland@arm.com> Cc: Julien Thierry <julien.thierry@arm.com>, Arnd Bergmann <arnd@arndb.de>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Catalin Marinas <catalin.marinas@arm.com>, Jiri Kosina <jikos@kernel.org>, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>, AKASHI Takahiro <takahiro.akashi@linaro.org>, Ingo Molnar <mingo@redhat.com>, Ruslan Bilovol <ruslan.bilovol@gmail.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Amit Daniel Kachhap <amit.kachhap@arm.com>, live-patching@vger.kernel.org, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v8 0/5] arm64: ftrace with regs Date: Sat, 19 Oct 2019 13:01:35 +0200 [thread overview] Message-ID: <20191019130135.10de9324@blackhole.lan> (raw) In-Reply-To: <20191018174100.GC18838@lakrids.cambridge.arm.com> Hi Mark! On Fri, 18 Oct 2019 18:41:02 +0100 Mark Rutland <mark.rutland@arm.com> wrote: > In the process of reworking this I spotted some issues that will get > in the way of livepatching. Notably: > > * When modules can be loaded far away from the kernel, we'll > potentially need a PLT for each function within a module, if each can > be patched to a unique function. Currently we have a fixed number, > which is only sufficient for the two ftrace entry trampolines. > > IIUC, the new code being patched in is itself a module, in which > case we'd need a PLT for each function in the main kernel image. When no live patching is involved, obviously all cases need to have been handled so far. And when a live patching module comes in, there are calls in and out of the new patch code: Calls going into the live patch are not aware of this. They are caught by an active ftrace intercept, and the actual call into the LP module is done in klp_arch_set_pc, by manipulating the intercept (call site) return address (in case thread lives in the "new world", for completeness' sake). This is an unsigned long write in C. All calls going _out_ from the KLP module are newly generated, as part of the KLP module building process, and are thus aware of them being "extern" -- a PLT entry should be generated and accounted for in the KLP module. > We have a few options here, e.g. changing which memory size model we > use, or reserving space for a PLT before each function using > -f patchable-function-entry=N,M. Nonetheless I'm happy I once added the ,M option here. You never know :) > * There are windows where backtracing will miss the callsite's caller, > as its address is not live in the LR or existing chain of frame > records. Thus we cannot claim to have a reliable stacktrace. > > I suspect we'll have to teach the stacktrace code to handle this as > a special-case. Yes, that's where I had to step back. The unwinder needs to stop where the chain is even questionable. In _all_ cases. Missing only one race condition means a lurking inconsistency. OTOH it's not a problem to report "not reliable" when in doubt; the thread in question will then get woken up and unwind itself. It is only an optimisation to let all kernel threads which are guaranteed to not contain any patched functions sleep on. > I'll try to write these up, as similar probably applies to other > architectures with a link register. I thought I'd quickly give you my feedback upfront here. Torsten _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-19 11:02 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-08 15:08 [PATCH v8 0/5] arm64: ftrace with regs Torsten Duwe 2019-02-08 15:08 ` Torsten Duwe 2019-02-08 15:10 ` [PATCH v8 1/5] arm64: replace -pg with CC_FLAGS_FTRACE in arm64 Makefiles Torsten Duwe 2019-02-08 15:10 ` Torsten Duwe 2019-02-11 11:53 ` Mark Rutland 2019-02-11 11:53 ` Mark Rutland 2019-02-08 15:10 ` [PATCH v8 2/5] arm64: replace -pg with CC_FLAGS_FTRACE in efi Makefiles Torsten Duwe 2019-02-08 15:10 ` Torsten Duwe 2019-02-11 11:59 ` Mark Rutland 2019-02-11 11:59 ` Mark Rutland 2019-04-08 15:23 ` Mark Rutland 2019-04-08 15:23 ` Mark Rutland 2019-04-08 20:49 ` Ard Biesheuvel 2019-04-08 20:49 ` Ard Biesheuvel 2019-02-08 15:10 ` [PATCH v8 3/5] arm64: replace -pg with CC_FLAGS_FTRACE in mm/kasan Makefile Torsten Duwe 2019-02-08 15:10 ` Torsten Duwe 2019-02-11 11:55 ` Mark Rutland 2019-02-11 11:55 ` Mark Rutland 2019-02-11 11:56 ` Mark Rutland 2019-02-11 11:56 ` Mark Rutland 2019-04-08 15:25 ` Mark Rutland 2019-04-08 15:25 ` Mark Rutland 2019-04-08 15:35 ` Andrey Ryabinin 2019-04-08 15:35 ` Andrey Ryabinin 2019-02-08 15:10 ` [PATCH v8 4/5] arm64: implement ftrace with regs Torsten Duwe 2019-02-08 15:10 ` Torsten Duwe 2019-02-13 10:30 ` Julien Thierry 2019-02-13 10:30 ` Julien Thierry 2019-02-08 15:10 ` [PATCH v8 5/5] arm64: use -fpatchable-function-entry if available Torsten Duwe 2019-02-08 15:10 ` Torsten Duwe 2019-02-13 11:11 ` [PATCH v8 0/5] arm64: ftrace with regs Julien Thierry 2019-02-13 11:11 ` Julien Thierry 2019-03-11 11:49 ` Torsten Duwe 2019-03-11 11:49 ` Torsten Duwe 2019-03-11 12:18 ` Mark Rutland 2019-03-11 12:18 ` Mark Rutland 2019-03-29 10:18 ` Torsten Duwe 2019-03-29 10:18 ` Torsten Duwe 2019-04-08 15:36 ` Mark Rutland 2019-04-08 15:36 ` Mark Rutland 2019-04-09 17:52 ` Will Deacon 2019-04-09 17:52 ` Will Deacon 2019-07-10 12:27 ` Ruslan Bilovol 2019-07-10 12:27 ` Ruslan Bilovol 2019-07-24 16:15 ` Mark Rutland 2019-07-24 16:15 ` Mark Rutland 2019-10-16 11:42 ` Jiri Kosina 2019-10-16 11:42 ` Jiri Kosina 2019-10-16 17:58 ` Mark Rutland 2019-10-16 17:58 ` Mark Rutland 2019-10-18 17:41 ` Mark Rutland 2019-10-18 17:41 ` Mark Rutland 2019-10-19 11:01 ` Torsten Duwe [this message] 2019-10-19 11:01 ` Torsten Duwe 2019-10-21 11:37 ` Mark Rutland 2019-10-21 11:37 ` Mark Rutland 2019-10-21 13:20 ` Josh Poimboeuf 2019-10-21 13:20 ` Josh Poimboeuf
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191019130135.10de9324@blackhole.lan \ --to=duwe@lst.de \ --cc=amit.kachhap@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=jikos@kernel.org \ --cc=jpoimboe@redhat.com \ --cc=julien.thierry@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=live-patching@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mingo@redhat.com \ --cc=rostedt@goodmis.org \ --cc=ruslan.bilovol@gmail.com \ --cc=takahiro.akashi@linaro.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.