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

Zachary Amsden
2006-05-16T09:02:25Z

Chris Wright wrote:
> * Zachary Amsden (zach@vmware.com) 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