Date:   Tue, 23 Feb 2021 12:12:42 -0600
From:   madvenka@...ux.microsoft.com
To:     broonie@...nel.org, mark.rutland@....com, jpoimboe@...hat.com,
        jthierry@...hat.com, linux-arm-kernel@...ts.infradead.org,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
        madvenka@...ux.microsoft.com
Subject: [RFC PATCH v1 0/1] arm64: Unwinder enhancements for reliable stack trace

From: "Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>

I have made an attempt to add some enhancements to the stack trace code
so it is a few steps closer to what is required for livepatch.

Unwinder changes
================

	Termination
	===========

	Currently, the unwinder terminates when both the FP (frame pointer)
	and the PC (return address) of a frame are 0. But a frame could get
	corrupted and zeroed. There needs to be a better check.

	The following special terminating frame and function have been
	defined for this purpose:

	const u64    arm64_last_frame[2] __attribute__ ((aligned (16)));

	void arm64_last_func(void)
	{
	}

	In this patch, the FP is set to arm64_last_frame and the PC is set
	to arm64_last_func in the bottom most frame.

	Exception/Interrupt detection
	=============================

	An EL1 exception renders the stack trace unreliable as it can happen
	anywhere including the frame pointer prolog and epilog. The
	unwinder needs to be able to detect the exception on the stack.

	Currently, the EL1 exception handler sets up pt_regs on the stack.
	pt_regs contains a stack frame field that can hold an FP and a PC.
	The exception handler chains this stack frame field along with other
	frames on the stack. In other words, the EL1 handler creates a
	synthetic exception frame. Currently, the unwinder does not know
	where this exception frame is in the stack trace.

	In this patch, the LSB of the exception frame FP is set. This is
	similar to what is done on X86. When the unwinder detects the frame
	with the LSB set, it needs to make sure that it is really an
	exception frame and not the result of any stack corruption.

	It can do this if the FP and PC are also recorded elsewhere in the
	pt_regs for comparison. Currently, the FP is also stored in
	regs->regs[29]. The PC is stored in regs->pc. However, regs->pc can
	be changed by lower level functions. So, the PC needs to be stored
	somewhere else as well.

	This patch defines a new field, pt_regs->orig_pc, and records the
	PC there. With this, the unwinder can validate the exception frame
	and set a flag so that the caller of the unwinder can know when
	an exception frame is encountered.

	Unwinder return value
	=====================

	Currently, the unwinder returns -EINVAL for stack trace termination
	as well as stack trace error. In this patch, the unwinder returns
	-ENOENT for stack trace termination and -EINVAL for error. This idea
	has been plagiarized from Mark Brown.

Reliable stack trace function
=============================

arch_stack_walk_reliable() is implemented in this patch. It walks the
stack like the existing stack trace functions with a couple of additional
checks:

	Return address check
	--------------------

	For each frame, the return address is checked to see if it is
	a proper kernel text address. If not, the stack walk fails.

	Exception frame check
	---------------------

	Each frame is checked to see if it is an EL1 exception frame.
	If it is, the stack walk fails.

Signed-off-by: Madhavan T. Venkataraman <madvenka@...ux.microsoft.com>

Madhavan T. Venkataraman (1):
  arm64: Unwinder enhancements for reliable stack trace

 arch/arm64/include/asm/processor.h  |   2 +
 arch/arm64/include/asm/ptrace.h     |   7 ++
 arch/arm64/include/asm/stacktrace.h |   5 ++
 arch/arm64/kernel/asm-offsets.c     |   1 +
 arch/arm64/kernel/entry.S           |  14 +++-
 arch/arm64/kernel/head.S            |   8 +--
 arch/arm64/kernel/process.c         |  12 ++++
 arch/arm64/kernel/stacktrace.c      | 103 +++++++++++++++++++++++++---
 8 files changed, 137 insertions(+), 15 deletions(-)


base-commit: e0756cfc7d7cd08c98a53b6009c091a3f6a50be6
-- 
2.25.1

Powered by blists - more mailing lists