vDSO(7)

💫 vDSO — the virtual ELF dynamic shared object, explained by your favorite Unix bestie

okay so bestie, buckle up, because vdso is one of those things that sounds scary and is actually so cute once you get it. it's the virtual dynamic shared object. yes, that's a mouthful. we're gonna make it make sense. 🦋

---

✨ NAME ✨

vdso — like, a whole overview of the virtual ELF dynamic shared object. that's it, that's the name. 💅

---

🎀 SYNOPSIS 🎀

#include <sys/auxv.h>

void *vdso = (uintptr_t) getauxval(AT_SYSINFO_EHDR);

that's the whole vibe right there. you pull the address out of the auxiliary vector and now you're holding the vDSO in your hands. main character moment fr fr. 💖

---

🌸 DESCRIPTION 🌸

so. the "vDSO" (virtual dynamic shared object) is a small shared library that the kernel just… automatically maps into the address space of all user-space applications. like the kernel is being so generous, no cap. 🫶

and here's the thing — applications usually do not need to concern themselves with any of these details, because the vDSO is most commonly called by the C library. so you get to code in the normal way, using standard functions, and the C library handles all the "ooh what functionality is available via the vDSO" business for you. iconic behavior honestly.

but wait. why does the vDSO exist at all? great question, i was hoping you'd ask. 😭

there are some system calls the kernel provides that user-space code ends up using constantly — to the point that those calls can dominate overall performance. this happens for two reasons:

• the raw frequency of the call, and
• the context-switch overhead you eat from exiting user space and entering the kernel.

and the rest of this documentation? it's geared toward the curious and/or C library writers, not general developers. so if you're out here trying to call the vDSO directly in your own application instead of just using the C library… bestie, you're most likely doing it wrong. 💀 (affectionately!! but seriously!!)

🧚 Example background

making system calls can be slow. that's the tea. ☕

on x86 32-bit systems, you can trigger a software interrupt (int $0x80) to tell the kernel you wish to make a system call. but this instruction is expensive — it goes through the full interrupt-handling paths in the processor's microcode as well as in the kernel. lowkey tragic.

newer processors have faster (but backward incompatible) instructions to initiate system calls. and rather than require the C library to figure out at run time whether this functionality is available, the C library can just use functions provided by the kernel in the vDSO. slay. ✨

note that the terminology can be confusing, and that's not on you. on x86 systems, the vDSO function used to determine the preferred method of making a system call is named __kernel_vsyscall. but on x86-64, the term "vsyscall" also refers to an obsolete way to ask the kernel what time it is or what CPU the caller is on. two different things, same-sounding name. ikykyk. 🙈

one frequently used system call is gettimeofday(2). this system call is called both directly by user-space applications and indirectly by the C library. think timestamps, timing loops, polling — all of these frequently need to know what time it is right now. ⏰

and this information is also not secret — any application in any privilege mode (root or any unprivileged user) will get the same answer. so the kernel arranges for the information required to answer this question to be placed in memory the process can access. and boom, a call to gettimeofday(2) changes from a system call to a normal function call and a few memory accesses. Ate. 🔥

🦋 Finding the vDSO

the base address of the vDSO (if one exists) is passed by the kernel to each program in the initial auxiliary vector (see getauxval(3)), via the AT_SYSINFO_EHDR tag. that's your golden ticket. 🎫

you must not assume the vDSO is mapped at any particular location in the user's memory map. the base address will usually be randomized at run time every time a new process image is created (at execve(2) time). this is done for security reasons, to prevent "return-to-libc" attacks. so no hardcoding, bestie, i'm begging. 😤

for some architectures, there is also an AT_SYSINFO tag. this is used only for locating the vsyscall entry point, and it is frequently omitted or set to 0 (meaning it's not available). this tag is a throwback to the initial vDSO work (see History below) and its use should be avoided. it's giving legacy. avoid it. 💅

💜 File format

since the vDSO is a fully formed ELF image, you can do symbol lookups on it. that's the fun part. this allows new symbols to be added with newer kernel releases, and it allows the C library to detect available functionality at run time when running under different kernel versions. and oftentimes the C library will do that detection on the first call and then cache the result for subsequent calls. efficiency queen. 👑

all symbols are also versioned (using the GNU version format). this allows the kernel to update the function signature without breaking backward compatibility — which means changing the arguments that the function accepts as well as the return value. so when you're looking up a symbol in the vDSO, you must always include the version to match the ABI you expect. do not skip this. nope. 🚫

typically the vDSO follows the naming convention of prefixing all symbols with __vdso_ or __kernel_, so as to distinguish them from other standard symbols. for example, the "gettimeofday" function is named __vdso_gettimeofday. cute little prefix, very demure. 🎀

and you use the standard C calling conventions when calling any of these functions. no need to worry about weird register or stack behavior. that's a relief, honestly. 😮‍💨

---

⭐ NOTES ⭐

🌈 Source

when you compile the kernel, it will automatically compile and link the vDSO code for you. so thoughtful. you will frequently find it under the architecture-specific directory:

find arch/$ARCH/ -name '*vdso*.so*' -o -name '*gate*.so*'

go forth and find, bestie. 🔍

🍓 vDSO names

the name of the vDSO varies across architectures. it will often show up in things like glibc's ldd(1) output. but the exact name should not matter to any code, so do not hardcode it. ever. i mean it. 😭

here's the whole lineup, one per architecture:

• user ABI aarch64 — vDSO name: linux-vdso.so.1
• user ABI arm — vDSO name: linux-vdso.so.1
• user ABI ia64 — vDSO name: linux-gate.so.1
• user ABI mips — vDSO name: linux-vdso.so.1
• user ABI ppc/32 — vDSO name: linux-vdso32.so.1
• user ABI ppc/64 — vDSO name: linux-vdso64.so.1
• user ABI riscv — vDSO name: linux-vdso.so.1
• user ABI s390 — vDSO name: linux-vdso32.so.1
• user ABI s390x — vDSO name: linux-vdso64.so.1
• user ABI sh — vDSO name: linux-gate.so.1
• user ABI i386 — vDSO name: linux-gate.so.1
• user ABI x86-64 — vDSO name: linux-vdso.so.1
• user ABI x86/x32 — vDSO name: linux-vdso.so.1

so many names, same energy. 🌸

🔥 strace(1), seccomp(2), and the vDSO

this is the part that gets people every single time, so listen up. 👂

when tracing system calls with strace(1), symbols (system calls) that are exported by the vDSO will not appear in the trace output.

and those same system calls will likewise not be visible to seccomp(2) filters.

so if you're out here like "why isn't my syscall showing up in strace??" — girl, it's the vDSO. it went around the system call entirely. that's the whole point of it. 🙈

---

to be continued, bestie — there's a part 2 coming, so don't go anywhere. 💖

🏗️ ARCHITECTURE-SPECIFIC NOTES 🏗️

okay bestie, the sections below are the per-architecture tea on the vDSO — every arch does its own lil thing and honestly? iconic behavior. 💅

First rule of vDSO club, no cap: which vDSO you actually get depends on the ABI of your user-space code, not the ABI of the kernel. so like — when you run an i386 32-bit ELF binary, you get the exact same vDSO whether you're running it under an i386 32-bit kernel or under an x86-64 64-bit kernel. it literally does not care. 🫶 so to figure out which of these sections is even relevant to you, use the name of the user-space ABI. periodt.

---

🌸 ARM functions

here's the table of symbols the vDSO is out here exporting:

symbol                 version
────────────────────────────────────────────────────────────
__vdso_gettimeofday    LINUX_2.6 (exported since Linux 4.1)
__vdso_clock_gettime   LINUX_2.6 (exported since Linux 4.1)

PLUS the ARM port has a whole code page full of utility functions. lowkey feral. but since it's just a raw page of code, there's no ELF information for doing symbol lookups or versioning. it does support different versions though, so that's something. ✨

For the deep dive on this code page, bestie, go straight to the kernel documentation — it is extremely detailed and covers literally everything you need: Documentation/arm/kernel_user_helpers.rst.

✨ aarch64 functions

the vDSO symbols, served fresh:

symbol                   version
──────────────────────────────────────
__kernel_rt_sigreturn    LINUX_2.6.39
__kernel_gettimeofday    LINUX_2.6.39
__kernel_clock_gettime   LINUX_2.6.39
__kernel_clock_getres    LINUX_2.6.39

🐟 bfin (Blackfin) functions (port removed in Linux 4.17)

okay so this CPU has no MMU (memory management unit), so it doesn't set up a vDSO in the normal sense at all. instead, it maps a few raw functions into a fixed location in memory at boot time, and user-space apps just call directly into that region. there's no provision for backward compatibility beyond sniffing raw opcodes — but it's an embedded CPU so it can get away with things, honestly. some of the object formats it runs aren't even ELF based (they're bFLT/FLAT). 💀

For the tea on this code page, refer to the public documentation: http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:fixed-code

🌀 mips functions

the vDSO exports, handheld with care:

symbol                   version
──────────────────────────────────────────────
__kernel_gettimeofday    LINUX_2.6 (exported since Linux 4.4)
__kernel_clock_gettime   LINUX_2.6 (exported since Linux 4.4)

🛸 ia64 (Itanium) functions

the vDSO symbols:

symbol                       version
───────────────────────────────────────
__kernel_sigtramp            LINUX_2.5
__kernel_syscall_via_break   LINUX_2.5
__kernel_syscall_via_epc     LINUX_2.5

ngl the Itanium port is somewhat tricky. 😭 on top of the vDSO above, it also has "light-weight system calls" (aka "fast syscalls" aka "fsys"). you invoke these through the __kernel_syscall_via_epc vDSO helper. the syscalls listed here have the exact same semantics as if you called them directly via syscall(2), so go read the relevant docs for each one. here's what's available through this mechanism:

function
────────────────
clock_gettime
getcpu
getpid
getppid
gettimeofday
set_tid_address

🚪 parisc (hppa) functions

the parisc port has a code page with utility functions called a gateway page. instead of using the normal ELF auxiliary vector approach, it passes the address of the page to the process via the SR2 register. 🫶 the permissions on the page are set up so that merely executing those addresses automatically executes with kernel privileges and not in user space. this is done to match the way HP-UX works, iykyk.

and since it's just a raw page of code, there's no ELF information for doing symbol lookups or versioning. you literally just call into the appropriate offset via the branch instruction, for example:

ble <offset>(%sr2, %r0)

here's the offset map:

offset   function
────────────────────────────────────────────
00b0     lws_entry (CAS operations)
00e0     set_thread_pointer (used by glibc)
0100     linux_gateway_entry (syscall)

⚡ ppc/32 functions

the vDSO exports — and heads up, the functions marked with a * are available only when the kernel is a PowerPC64 (64-bit) kernel:

symbol                     version
────────────────────────────────────────
__kernel_clock_getres      LINUX_2.6.15
__kernel_clock_gettime     LINUX_2.6.15
__kernel_clock_gettime64   LINUX_5.11
__kernel_datapage_offset   LINUX_2.6.15
__kernel_get_syscall_map   LINUX_2.6.15
__kernel_get_tbfreq        LINUX_2.6.15
__kernel_getcpu *          LINUX_2.6.15
__kernel_gettimeofday      LINUX_2.6.15
__kernel_sigtramp_rt32     LINUX_2.6.15
__kernel_sigtramp32        LINUX_2.6.15
__kernel_sync_dicache      LINUX_2.6.15
__kernel_sync_dicache_p5   LINUX_2.6.15

⚠️ Before Linux 5.6, the CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE clocks are not supported by the __kernel_clock_getres and __kernel_clock_gettime interfaces — the kernel falls back to the real system call. so no shortcuts for you there. 💀

⚡ ppc/64 functions

the vDSO exports:

symbol                     version
────────────────────────────────────────
__kernel_clock_getres      LINUX_2.6.15
__kernel_clock_gettime     LINUX_2.6.15
__kernel_datapage_offset   LINUX_2.6.15
__kernel_get_syscall_map   LINUX_2.6.15
__kernel_get_tbfreq        LINUX_2.6.15
__kernel_getcpu            LINUX_2.6.15
__kernel_gettimeofday      LINUX_2.6.15
__kernel_sigtramp_rt64     LINUX_2.6.15
__kernel_sync_dicache      LINUX_2.6.15
__kernel_sync_dicache_p5   LINUX_2.6.15

⚠️ And same energy as before: before Linux 4.16, the CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE clocks are not supported by __kernel_clock_getres and __kernel_clock_gettime; the kernel is like "fine, I'll do it myself" and falls back to the real system call. 😤

🌋 riscv functions

the vDSO exports, freshly brewed:

symbol                 version
──────────────────────────────────
__vdso_rt_sigreturn    LINUX_4.15
__vdso_gettimeofday    LINUX_4.15
__vdso_clock_gettime   LINUX_4.15
__vdso_clock_getres    LINUX_4.15
__vdso_getcpu          LINUX_4.15
__vdso_flush_icache    LINUX_4.15

💠 s390 functions

the vDSO exports:

symbol                   version
──────────────────────────────────────
__kernel_clock_getres    LINUX_2.6.29
__kernel_clock_gettime   LINUX_2.6.29
__kernel_gettimeofday    LINUX_2.6.29

💠 s390x functions

the vDSO exports (yes, same lil trio 🫶):

symbol                   version
──────────────────────────────────────
__kernel_clock_getres    LINUX_2.6.29
__kernel_clock_gettime   LINUX_2.6.29
__kernel_gettimeofday    LINUX_2.6.29

🚀 sh (SuperH) functions

the vDSO exports:

symbol                  version
──────────────────────────────────
__kernel_rt_sigreturn   LINUX_2.6
__kernel_sigreturn      LINUX_2.6
__kernel_vsyscall       LINUX_2.6

💻 i386 functions

the vDSO exports, serving 32-bit realness:

symbol                  version
──────────────────────────────────────────────────────────────
__kernel_sigreturn      LINUX_2.5
__kernel_rt_sigreturn   LINUX_2.5
__kernel_vsyscall       LINUX_2.5
__vdso_clock_gettime    LINUX_2.6 (exported since Linux 3.15)
__vdso_gettimeofday     LINUX_2.6 (exported since Linux 3.15)
__vdso_time             LINUX_2.6 (exported since Linux 3.15)

🖥️ x86-64 functions

the vDSO exports:

symbol                 version
─────────────────────────────────
__vdso_clock_gettime   LINUX_2.6
__vdso_getcpu          LINUX_2.6
__vdso_gettimeofday    LINUX_2.6
__vdso_time            LINUX_2.6

👑 bestie listen: all of these symbols are also available without the __vdso_ prefix. but you should ignore those and stick to the names above, ok? we do not use the off-brand ones. 💅

🖥️ x86/x32 functions

the vDSO exports:

symbol                 version
─────────────────────────────────
__vdso_clock_gettime   LINUX_2.6
__vdso_getcpu          LINUX_2.6
__vdso_gettimeofday    LINUX_2.6
__vdso_time            LINUX_2.6

📜 History

okay so the vDSO started as literally just a single function — the vsyscall. in older kernels you might see that name in a process's memory map instead of vdso. over time people realized this mechanism was a great way to pass more functionality to user space, so it got reconceived as a vDSO in the current format. glow-up of the century honestly. ✨🌈

---

👀 SEE ALSO 👀

• syscalls(2)
• getauxval(3)
• proc(5)

And the documents, examples, and source code chilling in the Linux source code tree:

Documentation/ABI/stable/vdso
Documentation/ia64/fsys.rst
Documentation/vDSO/* (includes examples of using the vDSO)

you can also go hunting for the files yourself with:

find arch/ -iname '*vdso*' -o -iname '*gate*'

some more reading material for your lil rabbit hole moment 📚:

• http://articles.manugarg.com/systemcallinlinux2_6.html
• https://lwn.net/Articles/446528/
• http://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken
• http://www.trilithium.com/johan/2005/08/linux-gate/

---

and that's the whole page, bestie!! 🎀 this lil masterpiece comes to you from Linux man-pages 6.20, dated 2025-12-25, and it's the vDSO(7) page — go forth and syscall fast, you absolute icon 💖🦋✨