Messages in this thread | | | Date | Mon, 6 Jun 2011 10:07:53 -0400 | Subject | Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls | From | Brian Gerst <> |
| |
On Mon, Jun 6, 2011 at 9:58 AM, <pageexec@freemail.hu> wrote: > On 6 Jun 2011 at 8:43, Andrew Lutomirski wrote: > >> >> and it's less flexible >> > >> > why? as in, what kind of flexibility do you need that int xx can provide but a page >> > fault cannot? >> >> The ability to make time() fast when configured that way. > > true, nx and fast time() at vsyscall addresses will never mix. but it's a temporary > problem for anyone who cares, a trivial glibc patch fixes it. > >> >> and it could impact a fast path in the kernel. >> > >> > a page fault is never a fast path, after all the cpu has just taken an exception >> > (vs. the syscall/sysenter style actually fast user->kernel transition) and is >> > about to make page table changes (and possibly TLB flushes). >> >> Sure it is. It's a path that's optimized carefully and needs to be as >> fast as possible. Just because it's annoyingly slow doesn't mean we >> get to make it even slower. > > sorry, but stating that the pf handler is a fast path doesn't make it so ;). > the typical pf is caused by userland to either fill in non-present pages > or do c-o-w, a few well predicted conditional branches in those paths are > simply not measurable (actually, those conditional branches would not be > on those paths, at least they aren't in PaX). seriously, try it ;). > >> >> > another thing to consider for using the int xx redirection scheme (speaking >> >> > of which, it should just be an int3): >> >> >> >> Why? 0xcd 0xcc traps no matter what offset you enter it at. >> > >> > but you're wasting/abusing an IDT entry for no real gain (and it's lots of code >> > for such a little change). also placing sw interrupts among hw ones is what can >> > result in (ab)use like this: >> >> I think it's less messy than mucking with the page fault handler. > > do you know what that mucking looks like? ;) prepare for the most complex code > you've ever seen (it's in __bad_area_nosemaphore): > > 779 #ifdef CONFIG_X86_64 > 780 »·······if (mm && (error_code & PF_INSTR) && mm->context.vdso) { > 781 »·······»·······if (regs->ip == (unsigned long)vgettimeofday) { > 782 »·······»·······»·······regs->ip = (unsigned long)VDSO64_SYMBOL(mm->context.vdso, gettimeofday); > 783 »·······»·······»·······return; > 784 »·······»·······} else if (regs->ip == (unsigned long)vtime) { > 785 »·······»·······»·······regs->ip = (unsigned long)VDSO64_SYMBOL(mm->context.vdso, clock_gettime); > 786 »·······»·······»·······return; > 787 »·······»·······} else if (regs->ip == (unsigned long)vgetcpu) { > 788 »·······»·······»·······regs->ip = (unsigned long)VDSO64_SYMBOL(mm->context.vdso, getcpu); > 789 »·······»·······»·······return; > 790 »·······»·······} > 791 »·······} > 792 #endif
I like this approach, however since we're already in the kernel it makes sense just to run the normal syscall instead of redirecting to the vdso.
-- Brian Gerst -- 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/
| |