Re: Shadow stack backtrace command name

Hello,

Luis Machado <[email protected]> writes:

> Hi,
>
> On 12/20/23 15:35, Schimpe, Christina wrote:
>> Hi, 
>> 
>> Thanks a lot for your feedback. Please find my answers to your comments below.
>> 
>>>> Having in mind that that the shadow stack is not only a x86-specific
>>>> feature but can be seen as a generic concept we also considered that
>>>> it could be part of the existing backtrace command, e.g.:
>>>> - "bt -shadow"
>>>> (+) Short syntax
>>>> (+/-) Most of the settings of the bt command don't apply to the shadow
>>>> stack (frame arguments and info). This might cause confusion.
>>>>
>>>> For this option, it might make sense to introduce a new setting for
>>>> the bt command which is for shadow stack only, e.g. "-symbol-filename
>>> [on|off]".
>>>>
>>>> What are your thoughts on this topic? Any feedback and new ideas are
>>> welcome.
>>>
>>> I like the option of reusing whatever is possible to reuse from the current
>>> backtrace command, so "bt -shadow" seems like a sensible option.

I like it too.

>>> It doesn't seem to me like this command will be used a lot. I expect it will be
>>> useful only when we catch a fault due to a corrupt stack trace, so putting it within
>>> the more general "backtrace" option would accomplish that.
>>>
>>> With that said, depending on how shadow stack support is implemented in gdb, I
>>> expect gdb will automatically validate the stack trace against the shadow stack
>>> (maybe on a fault), and complain if they go out of sync. Does that sound
>>> reasonable? Maybe even display where the flow veered off course.
>> 
>> No, we don't plan to validate the stack trace in GDB, as we don't see much
>> additional value for the user.
>> In case of a CET violation the user will see a SEGV with CP specific 
>> si_code = 10 (SEGV_CPERR). Printing siginfo will help to find out the reason for SEGV.
>> Inspecting the shadow stack and normal bt will show where the traces got out of sync.
>
> Thanks for clarifying it. My understanding is that aarch64 will also use SEGV_CPERR for
> the GCS faults, so it will be in sync with CET regarding reporting.

Yes, that is true.

>>> AArch64 will have a counterpart of this, with the Guarded Control Stack (GCS)
>>> feature, so the more generic we make this, the better.
>> 
>> Would the option's name "-shadow" be suitable for the GCS? I find it difficult to come
>> up with a more generic name that would cover both.
>
> From this entry [1], looks like the term shadow stack is a reasonably generic way to refer
> to this feature. So I think it is a suitable name, and would work for GCS as well.
>
> [1] https://en.wikipedia.org/wiki/Shadow_stack

Yes, the Linux kernel patch series adding support for GCS¹ plugs into
generic code that uses the "shadow stack" terminology. E.g., AArch64
programs will call "prctl(PR_SET_SHADOW_STACK_STATUS, PR_SHADOW_STACK_ENABLE)"
to enable GCS, "map_shadow_stack()" to map it, etc.

So that name will already be familiar to programmers debugging an
app using GCS.

PS: FWIW, I'm in the middle of adding GCS support in GDB.

-- 
Thiago

¹ https://lore.kernel.org/linux-arm-kernel/[email protected]/