Hey Andi, Ingo, Thomas,
I ran across an oddity recently in the x86_64 vsyscall code.
Specifically I was looking at the vsyscall clock_gettime()
implementation in arch/x86/vdso/vclock_gettime.c, and noticed there is a
vsyscall gettimeofday implementation there too! This seems to duplicate
the do_vgettimeofday implementation in arch/x86/kernel/vsyscall_64.c
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.
I'm a little worried about just switching it out, and cleaning it up, as
I don't know enough yet about how the vgettimeofday is called from glibc
(I thought it was a static "jump to this page and run" mapping).
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?
thanks
-john
john stultz <[email protected]> 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
--
[email protected] -- Speaking for myself only.
On Sat, 2009-07-18 at 00:12 +0200, Andi Kleen wrote:
> john stultz <[email protected]> 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.
Hrmm. Can we deprecate the old method and push glibc to use the new one?
If we remove it the vsyscall interface will old glibc's fall-back
gracefully?
thanks
-john
john stultz <[email protected]> writes:
>
> Hrmm. Can we deprecate the old method and push glibc to use the new one?
That would break every old 64bit executable. Also not there are programs
who don't use glibc.
Also glibc's way of calling the vDSO is still somewhat inefficient
(although that could be probably fixed)
> If we remove it the vsyscall interface will old glibc's fall-back
> gracefully?
They would crash gracefully.
I had a couple of different transition plans, but they were all fairly
complicated and had various disadvantages, so in the end nothing got
done and the old code just left in.
-Andi
--
[email protected] -- Speaking for myself only.
Andi Kleen <[email protected]> writes:
> john stultz <[email protected]> writes:
>>
>> Hrmm. Can we deprecate the old method and push glibc to use the new one?
>
> That would break every old 64bit executable. Also not there are programs
s/not/note/
> who don't use glibc.
-Andi
--
[email protected] -- Speaking for myself only.
On Sat, 2009-07-18 at 08:07 +0200, Andi Kleen wrote:
> john stultz <[email protected]> writes:
> >
> > Hrmm. Can we deprecate the old method and push glibc to use the new one?
>
> That would break every old 64bit executable. Also not there are programs
> who don't use glibc.
>
> Also glibc's way of calling the vDSO is still somewhat inefficient
> (although that could be probably fixed)
>
> > If we remove it the vsyscall interface will old glibc's fall-back
> > gracefully?
>
> They would crash gracefully.
>
> I had a couple of different transition plans, but they were all fairly
> complicated and had various disadvantages, so in the end nothing got
> done and the old code just left in.
Ok. Ulrich mailed me with the same points earlier and here's what I
said:
It seems the options are:
1) Keep the old vsyscall gtod implementation as is, despite it
duplicating things. Maybe avoid the code duplication via inlined
functions.
2) Set the old vsyscall gtod to directly call the syscall.
Neither of these help to avoid the non-randomized syscall instruction.
And #2 punishes old users for no really good reason, so #1 is probably
the best approach.
I'll try to put a patch together next week just to try to clean things
up a bit.
If anyone has any other ideas, let me know.
thanks
-john
> Ok. Ulrich mailed me with the same points earlier and here's what I
> said:
Hopefully he can fix the terrible vsyscall code in glibc too.
> 1) Keep the old vsyscall gtod implementation as is, despite it
> duplicating things. Maybe avoid the code duplication via inlined
> functions.
>
> 2) Set the old vsyscall gtod to directly call the syscall.
There were some more like
3) Call from old vsyscall into new vDSO code. This needs to store
the randomized mapping address somewhere though.
Most options required a another page for each process.
And a couple of other variants.
> Neither of these help to avoid the non-randomized syscall instruction.
They used to be patched away to nops when not needed,
unfortunately that code was removed at some point. Perhaps
that should be readded. Most systems actually don't need them
(only those that need pmtimer)
so you don't have a static syscall entry point on them.
-Andi
--
[email protected] -- Speaking for myself only.