Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace

From: Mark Rutland <mark.rutland@arm.com>
To: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
Cc: Julien Thierry <jthierry@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Miroslav Benes <mbenes@suse.cz>, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace
Date: Tue, 2 Feb 2021 10:05:55 +0000	[thread overview]
Message-ID: <20210202100547.GA59049@C02TD0UTHF1T.local> (raw)
In-Reply-To: <ee088b05-229c-11b0-8ded-103977c54e6c@linux.microsoft.com>

On Mon, Feb 01, 2021 at 03:38:53PM -0600, Madhavan T. Venkataraman wrote:
> On 2/1/21 10:02 AM, Mark Rutland wrote:
> > On Mon, Feb 01, 2021 at 09:21:43AM -0600, Madhavan T. Venkataraman wrote:
> >> On 1/28/21 9:26 AM, Josh Poimboeuf wrote:
> >> Decoding
> >> ========
> >>
> >> To do all this, objtool has to decode only the following instructions.
> >>
> >>         - no-op
> >>         - return instruction
> >> 	- store register pair in frame pointer prolog
> >> 	- load register pair in frame pointer epilog
> >>
> >> This simplifies the objtool part a lot. AFAIK, all instructions in ARM64 are
> >> 32 bits wide. So, objtool does not have to decode an instruction to know its
> >> length.
> >>
> >> Objtool has to scan a function for the return instruction to know the location(s)
> >> of the epilog.
> > 
> > That wouldn't be robust if you consider things like:
> > 
> > | func:
> > | 	STP	x29, x30, [SP, #-FRAME_SIZE]!
> > |	MOV	X29, SP
> > | 	B	__fake_ret
> > |	LDP	X29, X30, [SP], #FRAME_SIZE
> > |	RET
> > | __fake_ret:
> > | 	BL	x30
> > 
> > ... which is the sort of thing we want objtool to catch.
> 
> Objtool has to follow all the code paths to check every single possible return
> as I mentioned above.

Here I was pointing out that in order to do so you need to decode and
reason about more than NOP, RET, STP, and LDP, and you need to reason
about the logical function of an instruction (e.g. here the last LDP is
emulating a RET).

> 
> > [...]
> > 
> >> Unwinder logic
> >> ==============
> >>
> >> The unwinder will walk the stack using frame pointers like it does
> >> currently. As it unwinds the regular stack, it will also unwind the
> >> shadow stack:
> >>
> >> However, at each step, it needs to perform some additional checks:
> >>
> >>         symbol = lookup symbol table entry for pc
> >>         if (!symbol)
> >>                 return -EINVAL;
> >>
> >>         if (symbol does not have proper prolog and epilog)
> >>                 return -EINVAL;
> > 
> > I think at this point, we haven't gained anything from using a shadow
> > stack, and I'd much rather we used objtool to gather any metadata needed
> > to make unwinding reliable without mandating a shadow stack.
> > 
> 
> I think we have gained something. Pushing the return addresses on the shadow stack
> and using them to unwind means that objtool does not have to decode every single
> instruction and track the changes to the stack and frame state.

I think that practically speaking it's necessary to track all potential
paths through functions that may alter the shadow stack or the shadow
stack pointer to ensure that the manipulation is well-balanced and that
the shadow stack pointer isn't corrupted.

Practically speaking, this requires decoding a significant number of
instructions, and tracing through all potential paths a function may
take.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel