{"id":107043,"date":"2022-08-24T07:00:00","date_gmt":"2022-08-24T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107043"},"modified":"2022-11-29T09:23:12","modified_gmt":"2022-11-29T17:23:12","slug":"20220824-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220824-00\/?p=107043","title":{"rendered":"The AArch64 processor (aka arm64), part 21: Classic function prologues and epilogues"},"content":{"rendered":"

Classic function prologues in Windows on AArch64 follow a common pattern. I’ll present the full prologue, and then we’ll take it apart instruction by instruction.<\/p>\n

\u00a0<\/div>\n
    ; return address protection\r\n    pacibsp\r\n\r\n    ; saving registers\r\n    stp     fp, lr, [sp, #-0x30]!\r\n    stp     x19, x20, [sp, #0x10]\r\n    str     x21, [sp, #0x20]\r\n\r\n    ; establishing frame chain\r\n    mov     fp, sp\r\n\r\n    ; initializing GS cookie<\/a>\r\n    bl      __security_push_cookie\r\n\r\n    ; local variables and outbound parameters\r\n    sub     sp, sp, #0x80\r\n<\/pre>\n
The prologue breaks up into five sections, as marked off by comments above.<\/p>\n
On entry to the function, we have this:<\/p>\n\n\n\n\n\n\n\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
return address<\/td>\n <\/td>\n<\/tr>\n
previous fp<\/var><\/td>\n\u2190 fp<\/var> (frame chain)<\/td>\n<\/tr>\n
\u22ee<\/td>\n <\/td>\n<\/tr>\n
stack param<\/td>\n\u2190 sp<\/var><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The first order of business is to apply return address protection.<\/p>\n
Next, we save nonvolatile registers. We build the next stack frame by pushing fp<\/var> and lr<\/var> onto the stack into adjacent locations. The frame pointer and link register are always stored next to each other because that’s what stack walking requires. The “push” onto the stack is done by using a pre-incrementing store,\u00b9 so that the stack pointer is adjusted, and then the values written to the adjusted stack pointer.<\/p>\n
Let’s walk through that “push” again:<\/p>\n
    stp     fp, lr, [sp, #-0x30]!\r\n<\/pre>\n
The effective address is sp<\/var> \u2212 0x30<\/code>, which is 0x30<\/code> bytes below the current stack pointer. At that location, we store the fp<\/var> and lr<\/var> registers, and then the effective address is written back to the base register sp<\/var>.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
return address<\/td>\n <\/td>\n<\/tr>\n
previous fp<\/var><\/td>\n\u2190 fp<\/var> (frame chain)<\/td>\n<\/tr>\n
\u22ee<\/td>\n <\/td>\n<\/tr>\n
stack param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
return address<\/td>\n <\/td>\n<\/tr>\n
previous fp<\/var><\/td>\n\u2190 sp<\/var><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The next instruction stores the x19<\/var> and x20<\/var> registers into the register save area we just created.<\/p>\n
    stp     x19, x20, [sp, #0x10]\r\n<\/pre>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
return address<\/td>\n <\/td>\n<\/tr>\n
previous fp<\/var><\/td>\n\u2190 fp<\/var> (frame chain)<\/td>\n<\/tr>\n
\u22ee<\/td>\n <\/td>\n<\/tr>\n
stack param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
saved x20<\/var><\/td>\n <\/td>\n<\/tr>\n
saved x19<\/var><\/td>\n <\/td>\n<\/tr>\n
return address<\/td>\n <\/td>\n<\/tr>\n
previous fp<\/var><\/td>\n\u2190 sp<\/var><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
And the last instruction in the set saves the lone x21<\/var> register.<\/p>\n
    str     x21, [sp, #0x20]\r\n<\/pre>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
return address<\/td>\n <\/td>\n<\/tr>\n
previous fp<\/var><\/td>\n\u2190 fp<\/var> (frame chain)<\/td>\n<\/tr>\n
\u22ee<\/td>\n <\/td>\n<\/tr>\n
stack param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n<\/tr>\n
saved x21<\/var><\/td>\n <\/td>\n<\/tr>\n
saved x20<\/var><\/td>\n <\/td>\n<\/tr>\n
saved x19<\/var><\/td>\n <\/td>\n<\/tr>\n
return address<\/td>\n <\/td>\n<\/tr>\n
previous fp<\/var><\/td>\n\u2190 sp<\/var><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The stack must remain 16-byte aligned, which means that space must be reserved in multiples of 2 registers. We have an odd number of registers to save, so one of the spaces we reserved for the register save area goes to waste. (In theory, the compiler could decide to use it to record a local variable, but in practice it doesn’t.)<\/p>\n
The second part of the prologue re-establishes the frame chain.<\/p>\n
    ; link this frame onto the frame chain\r\n    mov     fp, sp\r\n<\/pre>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
 <\/td>\n <\/td>\n\u00a0<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nreturn address<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u25b6\ufe0e<\/td>\nprevious fp<\/var><\/td>\n\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n\u22ee<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nstack param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n\u00a0<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nsaved x21<\/var><\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nsaved x20<\/var><\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nsaved x19<\/var><\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nreturn address<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\nprevious fp<\/var><\/td>\n\u2190 fp<\/var> (frame chain), sp<\/td>\n<\/tr>\n
\u00a0<\/td>\n<\/tr>\n
 <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
If the function contains a stack-based array, then the prologue inserts the  GS cookie<\/a> onto the stack so that a buffer overflow from the stack-based array is likely to corrupt the cookie before it gets to the saved return address.<\/p>\n
    bl      __security_push_cookie\r\n<\/pre>\n
Even though the cookie is only the size of a register, the function pushes 16 bytes onto the stack due to the requirement that the stack remain 16-byte aligned.<\/p>\n
The cookie management functions use the xip0<\/var> and xip1<\/var> registers to do the work of calculating or validating the cookie. These registers are volatile and are assumed to be modified by any branch instruction, and we used a branch instruction to get to the start of the prologue, so we know that xip0<\/var> and xip1<\/var> cannot be used to pass information from the caller to the callee, not even for a nonstandard calling convention.<\/p>\n
Finally, the prologue allocates space for stack-based local variables and outbound parameters.<\/p>\n
    sub     sp, sp, #0x80\r\n<\/pre>\n
We then reach the function body with this stack layout:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
 <\/td>\n <\/td>\n\u00a0<\/td>\n <\/td>\n\u00a0<\/td>\n\u00a0<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nreturn address<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u25b6\ufe0e<\/td>\nprevious fp<\/var><\/td>\n\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n\u22ee<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nstack param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n\u00a0<\/td>\n <\/td>\n\u00a0<\/td>\nsaved
\nregister
\narea<\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nsaved x21<\/var><\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nsaved x20<\/var><\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nsaved x19<\/var><\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nreturn address<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\nprevious fp<\/var><\/td>\n\u2190 fp<\/var> (frame chain)<\/td>\n<\/tr>\n
\u00a0<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u00a0<\/td>\n <\/td>\n\u00a0<\/td>\nGS
\narea<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nGS cookie<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nlocal
\nvariables<\/td>\n		 <\/td>\n\u00a0<\/td>\nlocal
\nstack
\narea<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\noutbound
\nstack
\nparameters<\/td>\n		\u2190 sp<\/var><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
When the function returns, the above steps are reversed.<\/p>\n
    add     sp, sp, #0x80           ; discard local stack area\r\n    bl      __security_pop_cookie   ; validate and pop GS cookie\r\n    ldr     x21, [sp, #0x20]        ; restore register\r\n    ldp     x19, x20, [sp, #0x10]   ; restore registers\r\n    ldp     fp, lr, [sp], #0x30     ; restore register and pop\r\n    autibsp                         ; validate return address\r\n    ret                             ; return\r\n<\/pre>\n
The final ldp<\/code> uses the post-increment addressing mode so that the stack pointer is increased by 0x30<\/code> after the registers are loaded.<\/p>\n
Restoring the fp<\/var> register unlinks the current stack frame from the frame chain. And restoring the lr<\/var> register puts the return address back into lr<\/var>, which we validate, and then use in the ret<\/code> instruction to return to the caller.\u00b2<\/p>\n
Not all of these steps will be present in all function prologues. A function that has no stack-based local variables or outbound parameters will not create a local stack area. A function that has no stack-based arrays will not create a GS cookie. And a lightweight leaf function won’t even bother saving any registers or protecting the return address.<\/p>\n
Next time, we’ll look at special cases that will diverge from this traditional prologue\/epilogue pattern.<\/p>\n
\u00b9 Though since the offset is negative, you can think of it as a pre-decrementing<\/i> store.<\/p>\n
\u00b2 In AArch64, the program counter pc<\/var> is not a general-purpose register, so you don’t see the trick popular in AArch32 where the return address is popped into the pc<\/var> register to return to the caller. For AArch64, we see the more traditional pattern of restoring the return address into lr<\/var> and then explicitly returning to it.<\/p>\n
\n