Re: [PATCH] Gerd Hoffman's move-vsyscall-into-user-address-rangepatch

From: Zachary Amsden
Date: Tue May 16 2006 - 05:03:07 EST

Chris Wright wrote:
* Zachary Amsden (zach@xxxxxxxxxx) wrote:
Let's dive into it. How do you get the randomization without sacrificing syscall performance? Do you randomize on boot, dynamically, or on a per-process level?

The latter, on exec.

Because I can see some issues with per-process randomization that will certainly cost some amount of cycles on the system call path. Marginal perhaps, but that is exactly where you don't want to shed cycles unnecessarily, and the complexity of the whole thing will go up quite a bit I think.

The crux is here:

+ OFFSET(TI_sysenter_return, thread_info, sysenter_return);

+ /*
+ * Push current_thread_info()->sysenter_return to the stack.
+ * A tiny bit of offset fixup is necessary - 4*4 means the 4 words
+ * pushed above; +8 corresponds to copy_thread's esp0 setting.
+ */
+ pushl (TI_sysenter_return-THREAD_SIZE+8+4*4)(%esp)


and in binfmt_elf during exec thread_info->sysenter_return is setup
based on the randomized mapping it does for vdso

+ ti->sysenter_return = &SYSENTER_RETURN_OFFSET + addr;

I think it's not so bad, but I can't say I've benchmarked the cost.

Now that I see it, it doesn't look bad at all. I had imagined a host of holy horrors unfolding from it, but clearly that is not the case. I think there is still the sysexit path that needs some change, but in total, there should be almost zero cycle impact. I envisioned trying to get the thread info for the return address would be awkward, but you've already switched the stack at this point, so it is really almost free.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at