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); > ... > > - pushl $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. Zach
