Messages in this thread | | | Date | Thu, 4 Mar 2004 17:45:45 +0100 | From | Andrea Arcangeli <> | Subject | Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3) |
| |
On Thu, Mar 04, 2004 at 03:57:36AM -0500, Jakub Jelinek wrote: > On Wed, Mar 03, 2004 at 06:54:49PM -0800, john stultz wrote: > > On Wed, 2004-03-03 at 18:47, Andrea Arcangeli wrote: > > > And sysenter is at a fixed address in 2.6 x86 too (it doesn't even > > > change between different kernel compiles). > > > > Actually, the 4G patch pushes vsysenter down a page, and glibc seems to > > handle this properly. > > But the 4G/4G patch relinks the vDSO to the address it uses, this is no > big problem for glibc which of course doesn't use hardcoded address but > reads AT_SYSINFO{,_EHDR} values kernel passes to it. > > But the fixed vDSO location is a problem, exploits certainly appreciate > a fixed address at which they with high probability can enter the kernel. > > Ingo Molnar recently wrote a patch to randomize the vDSO address on > IA-32. Unfortunately it revealed some bugs in glibc where ld.so did not
do you have a link to the patch? (I don't see it in his homepage) just curious to see how much precious address space you're throwing at this randomization and in turn how many tries are needed to brute force.
if you really care so much about randomization vs performance, it would been a lot better if you implemented vsysenter in a completely different way: by exporting some position indipendent bytecode to userspace via a syscall, and have glibc loadup this code somewhere in the address space (truly random thing making it trivial to do the intra-page offsets with byte granularity) and have kernel exporting only data, not exeuctables in the address space. The executable bytecode would be returned by a syscall. That is something slower at startup but fairly secure, and it doesn't waste kernel or user address space. The max-performance way of x86 vsysenter and x86-64 vgettimeofday simply don't fit for your security object best IMHO, it wasn't designed for that and it's an hack to try to randomize it with page-offsets. Keeping a local copy of the vsyscall bytecode at different intra-page offsets is something sanely doable in userspace, doing it in kernel is hairy and non-natural thing to do for kernel (involve copies, replacation of the vsyscall page etc., so one can as well do the copy in a load_usyscall syscall when the dynamic linker is asked to run gettimeofday, so this page can also be swapped out). What kernel can do more or less naturally is to share the same _physical_ vsyscall "page" (w/o intra page offset differences making it trivial to brut), and export it at a different addresses for each task, that is what Ingo implemented I guess, but it's 4096 times * 3.5G faster to crack. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |