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

["Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>]

On 2/2/21 4:05 AM, Mark Rutland wrote:
> 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.

I thought about it some more since you don't like the shadow stack that much.
I think I can achieve what I want with a simpler design without any shadow
stack and with better performance than a shadow stack. It needs a slightly
changed prolog and epilog. Please review this and comment.

In this design, I need 8 bytes of storage for recording the current frame pointer
address. Space at the bottom of the stack can be reserved for this easily.
I will use cur_fp to refer to the value at that memory location.

For this discussion, fp refers to the frame pointer register and sp refers to the
stack pointer register.

The goal is - even if a function modifies fp and/or does not restore sp to its
correct value at the end, the prolog and epilog should manage it so that everything
works. To do this, the current frame pointer address is stored in fp as well as cur_fp.
Even if fp is modified, cur_fp will still point to the correct frame address.

Prolog
=======

The original prolog is:

- Push fp and return address on the stack
- fp = sp


The new prolog is:

- Save cur_fp on the stack
- Push fp, return address on the stack
- fp = sp
- cur_fp = fp

Epilog
======

The original epilog is:

- Pop fp and return address

The new epilog is:

- sp = cur_fp
- Pop fp and return address
- Restore cur_fp from the stack


I think this is pretty simple.

Unwinder
========


The unwinder will start the stack walk from cur_fp instead of fp. At each frame,
it will use the saved cur_fp instead of the saved fp. 

Also, at each step, it can know if fp was actually changed by the function in
the frame. The unwinder can optionally issue warnings.


Compiler issue
===============

This solution is geared towards the kernel only. It assumes that the stack
has a fixed size and alignment so the bottom of the stack can be reached
from the current sp.

So, the compiler has to support two prologs and epilogs, one pair for apps
and one pair for the kernel.

Since this is just a tiny bit of code, I don't think this is a problem.

Finally, objtool can verify the prolog and epilog.

Is this general solution acceptable? We can always work out details.

Madhavan

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