Recognize and mitigate ntoskrnl's return stack buffer clearing idiom

[bdash]

Version and Platform (required):

• Binary Ninja Version: 5.4.10362-dev Ultimate, bbfabaed
• OS: macos
• OS Version: 26.5.2
• CPU Architecture: arm64

Bug Description:
ntoskrnl.exe has a bunch of functions that look like this:

140ab5703    int64_t sub_140ab5703()

140ab5703     0* 4883c408           add     rsp, 0x8
140ab5707    -8  e8eeffffff         call    sub_140ab56fa  {sub_140ab570c}
{ Falls through into sub_140ab570c }


140ab570c    int64_t sub_140ab570c()

140ab570c     0* 4883c408           add     rsp, 0x8
140ab5710    -8  e8eeffffff         call    sub_140ab5703  {sub_140ab5715}
{ Falls through into sub_140ab5715 }


140ab5715    int64_t sub_140ab5715()

140ab5715     0* 4883c408           add     rsp, 0x8
140ab5719    -8  e8eeffffff         call    sub_140ab570c  {sub_140ab571e}
{ Falls through into sub_140ab571e }


140ab571e    int64_t sub_140ab571e()

140ab571e     0* 4883c408           add     rsp, 0x8
140ab5722    -8  e8eeffffff         call    sub_140ab5715  {sub_140ab5727}
{ Falls through into sub_140ab5727 }

These are called by KiFlushCurrentRsb and eventually bottom out in:

140ab5742    int64_t sub_140ab5742(int64_t arg1 @ 0x8)

140ab5742     0* 4883c408           add     rsp, 0x8
140ab5746    -8  0faee8             lfence  
140ab5749    -8  480fba242409       bt      qword [rsp {arg1}], 0x9
140ab574f    -8  7301               jae     0x140ab5752

140ab5751    -8  fb                 sti     

140ab5752    -8* 4883c410           add     rsp, 0x10
140ab5756   -18  c3                 retn     {arg_18}

This code appears to be a mitigation for a variant of Spectre 2 known as SpectreRSB.

The repeated add rsp, 0x8 / call pattern results in core computing diverging values for each functions' stack adjustment, that eventually leads to some number of them tripping the function update limit.

Steps To Reproduce:

1. Load ntoskrnl.exe (omega wheel directs safely).
2. Jump to KiFlushCurrentRsb.
3. Wait for analysis to finish, then look at the functions immediately after KiFlushCurrentRsb to see whether any generated excessive updates.
4. Jump to 0x140ab5739, and look at the value for current_function.stack_adjustment. It should not be excessively large (i.e., OffsetWithConfidence(value=377666247104, confidence=191) is bad).

Additional Information:
I noticed this while looking into what functions within ntoskrnl.exe are responsible for generating the most updates. These functions stood out since they hit the update count limit.

Since this is a Spectre mitigation, it's possible we'll see similar patterns within other kernels for x86_64 operating systems.

[rssor]

dumping some of my thoughts here: this is probably worth identifying and handling in the Arch or Platform implementations. A relocation could be used to rewrite the calls to a jump and nop out the adds. Alternatively, the architecture could lie about max instruction length specifically to peek ahead, but given that this is over 256 bytes it might be a bit too much.

Need to go survey to what the commonly used RSB shootdowns look like.