setjmp / longjmp

A naïve implementation of the shadow stack will not correctly handle setjmp and longjmp. These functions are frequently used as a mechanism to pass control non-locally as an interprocedural goto, which is useful for error handling. The setjmp call saves the register contents, including stack pointer and program counter, in a jmp_buf structure. A longjmpcall takes a previously populated jmp_buf as an argument and restores the registers saved in this structure. Since restoring the jmp_buf replaces the stack pointer and program counter, the stack is unwound and the program returns to the site of the setjmp call, this time with a non-zero return value from setjmp.

Scrash maintains its shadow stack by pushing a new frame upon entry to a function and popping it just prior to exiting the function. However, the default longjmp implementation is unaware of the Scrash shadow stack, and will not properly restore the shadow stack pointer as it does the regular stack pointer.

We address this problem by using CIL to introduce a new structure, scrash_jmp_buf, which replaces a regular jmp_buf. It has two fields: one to contain the old jmp_buf structure and one to store the shadow stack pointer. We then search for all calls to setjmp and longjmp and replace them with functions that properly maintain the shadow stack pointer in addition to the registers in jmp_buf.

Note that when calling setjmp in a threaded environment, we store the thread-specific shadow stack pointer (normally stored in thread-local storage) in the jmp_buf. This transformation is necessary because a thread's state in Scrash is described by the contents of the registers, stack pointer, and shadow stack pointer, all of which must be stored in jmp_buf for longjmp to work properly. On a longjmp call, we restore the stack pointer back into thread local storage.