Chris Wright wrote:
* Zachary Amsden ([email protected]) 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
