linux-kernel - Re: x86_64: vsyscall vs vdso

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <38b2ab8a0709170030k2b5dad5dja31edebf12ad9626@mail.gmail.com>
Date:	Mon, 17 Sep 2007 09:30:54 +0200
From:	"Francis Moreau" <francis.moro@...il.com>
To:	"Ulrich Drepper" <drepper@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: x86_64: vsyscall vs vdso

Hello Ulrich,

Thanks for taking time to respond !

On 9/16/07, Ulrich Drepper <drepper@...il.com> wrote:
> On 9/16/07, Francis Moreau <francis.moro@...il.com> wrote:
>> I'm a bit puzzled because vdso doesn't seem to be used on my fedora 7:
>> I just compiled a trivial program which just call gettimeofday() and
>> ld.so resolves this call with vsyscall's gettimeofday.
>>
>> Now I'm wondering when vdso is used, could anybody give me a clue ?
>
> F7 was released before the vdso for x86_64 was upstream so you should
> not expect anything else.  F8 will use the available vdso.  This
> doesn't just happen magically, changes to libc are needed.
>

You're right. I don't know why I thought vdso was older...

>
>> Another question: is vdso going to replace vsyscall at all ? If so how
>> are statically programs going to be handled ?
>
> Unfortunately the vsyscalls cannot ever go completely away.
> Statically linked apps, the bane of progress, will need them.  There
> are also people updating kernels but not the user userland code.
>

Does that mean we'll need to keep 3 different implementations of gtod
in the kernel forever ?

> What we will have to do in future is to make vsyscalls configurable.
> Both a compile time option and a runtime option (perhaps also under
> control of SELinux) are likely needed.

I think signal trampolines will still need them too. So making
vsyscalls configurable doesn't seem to work, does it ?

I took a look to glibc-2.4 and it doesn't seem to use
__kernel_vsyscall vsyscall. Am I wrong ? If so could you point me
where it's used in the code ?

Another not so related question, hope you don't mind :)
I'm having hard time to understand how ld.so is working, specially the
dynamic symbol resolution after looking at the glibc code and reading
the ELF specification.
Do you know any others documents that could help ?

Thanks a lot.
-- 
Francis
-
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/