| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <87eisfvtzv.fsf@basil.nowhere.org> Date: Sat, 18 Jul 2009 00:12:52 +0200 From: Andi Kleen <andi@...stfloor.org> To: john stultz <johnstul@...ibm.com> Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...x.de>, lkml <linux-kernel@...r.kernel.org> Subject: Re: Duplicate vsyscall/vdso gettimeofday implementations on x86_64 john stultz <johnstul@...ibm.com> writes: > I think the implementation in vclock_gettime.c is nice, as it mostly > reuses the clock_gettime() code, but I don't think it actually gets > called. It depends on what glibc uses. > Andi: You wrote the vclock_gettime.c, do you have any pointers about > where you were going with this? Is there a reason you didn't clean it up > when you implemented it originally? The old style vsyscall cannot call the vDSO because it doesn't know where it is mapped. And the new style vDSO cannot necessarily call the old one vsyscall because there were plans to removing the old style vsyscall for some new programs to avoid the last non randomized mapping (but that never got implemented). That is why there are two different ways to do this. Neither can also call into the kernel of course. In the current setup you could call into the static vsyscall, but that might need to be revised later. -Andi -- ak@...ux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists