[libc-commits] [libc] [libc] fortify jmp buffer for x86-64 (PR #112769)

[Schrodinger ZHU Yifan via libc-commits]

================
@@ -99,6 +99,10 @@
     "LIBC_CONF_SETJMP_AARCH64_RESTORE_PLATFORM_REGISTER": {
       "value": true,
       "doc": "Make setjmp save the value of x18, and longjmp restore it. The AArch64 ABI delegates this register to platform ABIs, which can choose whether to make it caller-saved."
+    },
+    "LIBC_CONF_SETJMP_ENABLE_FORTIFICATION": {
+      "value": true,
+      "doc": "Enable fortification for setjmp and longjmp."
----------------
SchrodingerZhu wrote:

> Reading the description of the linked PR https://github.com/llvm/llvm-project/pull/101110, it looks to me as if the idea is to encrypt the contents of jmp_buf so that if an attacker is able to access it in between setjmp and longjmp they can't read useful information out of it, and also to hash the data in setjmp and check the hash in longjmp so that the same attacker can't modify the jmp_buf without getting caught?

Yep, The main problem of `SJLJ` is that `jmpbuf` may not be well protected by traditional CFI protection like safe stacks/stack canaries as the continuation data structure can be dumped onto the stack after the frame header. 

> But it also looks as if the encryption and hash aren't serious cryptography – it's XOR and a fairly simple checksum, rather than anything like AES and SHA-256 – which means they're fast but provide only limited protection?

You are correct on the safety regards. I think the problem is that even with AESNI, ten rounds of AESENC or sth similar can still be super costly if `SJLJ` is used frequently.

On the other hand, I think we are already doing a bit more than bionic. see:
https://android.googlesource.com/platform/bionic/+/master/libc/arch-x86/bionic/setjmp.S

> Also, perhaps the doc string ought to mention that this is currently supported only for x86-64, and also only for Linux (since it depends on a syscall to invent random keys)?

Thank you for catching this. I did make some silly mistakes on guarding the feature in build.

https://github.com/llvm/llvm-project/pull/112769