{"id":107050,"date":"2022-08-25T07:00:00","date_gmt":"2022-08-25T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107050"},"modified":"2022-11-29T09:32:45","modified_gmt":"2022-11-29T17:32:45","slug":"20220825-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220825-00\/?p=107050","title":{"rendered":"The AArch64 processor (aka arm64), part 22: Other kinds of classic prologues and epilogues"},"content":{"rendered":"

Last time, we looked at traditional classic function prologues in Windows on AArch64. But there are variations.<\/p>\n

For variadic functions, there is a small adjustment to the traditional prologue: The top of the register save area contains spill space for the variadic register parameters. The variadic register parameters are at the top so that they nestle directly against the stack-based parameters, so that the entire variadic parameter list can be accessed uniformly in memory.<\/p>\n

For example, a function whose prototype is<\/p>\n

int something(int a, int b, ...);\r\n<\/pre>\n
could have a prologue that goes something like<\/p>\n
\u00a0<\/div>\n
    ; return address protection\r\n    pacibsp\r\n\r\n    ; saving registers + variadic parameters\r\n    stp     fp, lr, [sp, #-0x50]!\r\n    str     x19, [sp, #0x10]\r\n    stp     x2, x3, [sp, #0x20]     ; variadic registers go here\r\n    stp     x4, x5, [sp, #0x30]     ; variadic registers go here\r\n    stp     x6, x7, [sp, #0x40]     ; variadic registers go here\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
for a combined stack layout of<\/p>\n\n\n\n\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>\nr7<\/var> param<\/td>\n <\/td>\n\u00a0<\/td>\nsaved
\nregister
\narea<\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nr6<\/var> param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nr5<\/var> param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nr4<\/var> param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nr3<\/var> param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\nr2<\/var> param<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n <\/td>\n\u00a0<\/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
There is no change to the epilogue because variadic inbound register parameters don’t need to be preserved across the call.<\/p>\n
Another type of function that has a different prologue and epilogue is the lightweight leaf function. This is a function that does not catch any exceptions, does not use any stack (beyond the stack space provided by inbound stack-based parameters), and does not modify any nonvolatile registers. These functions do not need to set up a stack frame or declare exception unwind codes. Conversely, the operating system assumes that any function that lacks exception unwind codes is a lightweight leaf function.\u00b9 If the operating system needs to unwind an exception that occurs in a lightweight leaf function, it just unwinds to the address held in the lr<\/var> register without updating any registers.<\/p>\n
A third category of function is the shrink-wrapped function. This function starts out with a minimal stack frame (possibly none, posing as a lightweight leaf function), but conditionally optionally expands to a full stack frame. This is typically used for functions that have a fast early-exit.<\/p>\n
And of course, for any of these functions, the RET<\/code> could turn into a B<\/code> or BR<\/code> if a tail call optimization is in effect. Since the calling convention is caller-clean with many register-based parameters, tail call optimization doesn’t require the tail-called function to have an identical signature as the calling function. The tail call is in play as long as the tail-called function’s stack parameter size is less than or equal to the stack parameter size of the calling function.<\/p>\n
Okay, so that’s the prologue and epilogue. Next time, we’ll look at some code patterns you’ll see in the function body itself.<\/p>\n
\u00b9 This clause always catches out people who are trying to write Windows programs in assembly language. If you fail to declare unwind codes, then the operating system assumes you are a lightweight leaf function: It assumes that the return address is in the lr<\/var> register, and it will continue stack walking at whatever address happens to be in that register, with whatever stack happens to be active, and with whatever values happen to be in the nonvolatile registers. This prevents the exception handlers installed by outer frames from running, or at least from running correctly. If you’re lucky, the program is declared “corrupted, possible malware” by the kernel when it notices that the frame chain is nonsense. If you’re not lucky, the handler is called with invalid registers and an invalid stack, and things spiral out of control. And if you’re super-unlucky, an attacker may be able to use this for a remote code execution attack.<\/p>\n
\n