]> git.ipfire.org Git - thirdparty/man-pages.git/blob - man7/vdso.7
ioctl_console.2, ioctl_getfsmap.2, ioctl_iflags.2, ioctl_list.2, ioctl_ns.2, kcmp...
[thirdparty/man-pages.git] / man7 / vdso.7
1 .\" Written by Mike Frysinger <vapier@gentoo.org>
2 .\"
3 .\" %%%LICENSE_START(PUBLIC_DOMAIN)
4 .\" This page is in the public domain.
5 .\" %%%LICENSE_END
6 .\"
7 .\" Useful background:
8 .\" http://articles.manugarg.com/systemcallinlinux2_6.html
9 .\" https://lwn.net/Articles/446528/
10 .\" http://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken
11 .\" http://www.trilithium.com/johan/2005/08/linux-gate/
12 .\"
13 .TH VDSO 7 2016-05-09 "Linux" "Linux Programmer's Manual"
14 .SH NAME
15 vdso \- overview of the virtual ELF dynamic shared object
16 .SH SYNOPSIS
17 .B #include <sys/auxv.h>
18 .PP
19 .B void *vdso = (uintptr_t) getauxval(AT_SYSINFO_EHDR);
20 .SH DESCRIPTION
21 The "vDSO" (virtual dynamic shared object) is a small shared library that
22 the kernel automatically maps into the
23 address space of all user-space applications.
24 Applications usually do not need to concern themselves with these details
25 as the vDSO is most commonly called by the C library.
26 This way you can code in the normal way using standard functions
27 and the C library will take care
28 of using any functionality that is available via the vDSO.
29 .PP
30 Why does the vDSO exist at all?
31 There are some system calls the kernel provides that
32 user-space code ends up using frequently,
33 to the point that such calls can dominate overall performance.
34 This is due both to the frequency of the call as well as the
35 context-switch overhead that results
36 from exiting user space and entering the kernel.
37 .PP
38 The rest of this documentation is geared toward the curious and/or
39 C library writers rather than general developers.
40 If you're trying to call the vDSO in your own application rather than using
41 the C library, you're most likely doing it wrong.
42 .SS Example background
43 Making system calls can be slow.
44 In x86 32-bit systems, you can trigger a software interrupt
45 .RI ( "int $0x80" )
46 to tell the kernel you wish to make a system call.
47 However, this instruction is expensive: it goes through
48 the full interrupt-handling paths
49 in the processor's microcode as well as in the kernel.
50 Newer processors have faster (but backward incompatible) instructions to
51 initiate system calls.
52 Rather than require the C library to figure out if this functionality is
53 available at run time,
54 the C library can use functions provided by the kernel in
55 the vDSO.
56 .PP
57 Note that the terminology can be confusing.
58 On x86 systems, the vDSO function
59 used to determine the preferred method of making a system call is
60 named "__kernel_vsyscall", but on x86_64,
61 the term "vsyscall" also refers to an obsolete way to ask the kernel
62 what time it is or what CPU the caller is on.
63 .PP
64 One frequently used system call is
65 .BR gettimeofday (2).
66 This system call is called both directly by user-space applications
67 as well as indirectly by
68 the C library.
69 Think timestamps or timing loops or polling\(emall of these
70 frequently need to know what time it is right now.
71 This information is also not secret\(emany application in any
72 privilege mode (root or any unprivileged user) will get the same answer.
73 Thus the kernel arranges for the information required to answer
74 this question to be placed in memory the process can access.
75 Now a call to
76 .BR gettimeofday (2)
77 changes from a system call to a normal function
78 call and a few memory accesses.
79 .SS Finding the vDSO
80 The base address of the vDSO (if one exists) is passed by the kernel to
81 each program in the initial auxiliary vector (see
82 .BR getauxval (3)),
83 via the
84 .B AT_SYSINFO_EHDR
85 tag.
86 .PP
87 You must not assume the vDSO is mapped at any particular location in the
88 user's memory map.
89 The base address will usually be randomized at run time every time a new
90 process image is created (at
91 .BR execve (2)
92 time).
93 This is done for security reasons,
94 to prevent "return-to-libc" attacks.
95 .PP
96 For some architectures, there is also an
97 .B AT_SYSINFO
98 tag.
99 This is used only for locating the vsyscall entry point and is frequently
100 omitted or set to 0 (meaning it's not available).
101 This tag is a throwback to the initial vDSO work (see
102 .IR History
103 below) and its use should be avoided.
104 .SS File format
105 Since the vDSO is a fully formed ELF image, you can do symbol lookups on it.
106 This allows new symbols to be added with newer kernel releases,
107 and allows the C library to detect available functionality at
108 run time when running under different kernel versions.
109 Oftentimes the C library will do detection with the first call and then
110 cache the result for subsequent calls.
111 .PP
112 All symbols are also versioned (using the GNU version format).
113 This allows the kernel to update the function signature without breaking
114 backward compatibility.
115 This means changing the arguments that the function accepts as well as the
116 return value.
117 Thus, when looking up a symbol in the vDSO,
118 you must always include the version
119 to match the ABI you expect.
120 .PP
121 Typically the vDSO follows the naming convention of prefixing
122 all symbols with "__vdso_" or "__kernel_"
123 so as to distinguish them from other standard symbols.
124 For example, the "gettimeofday" function is named "__vdso_gettimeofday".
125 .PP
126 You use the standard C calling conventions when calling
127 any of these functions.
128 No need to worry about weird register or stack behavior.
129 .SH NOTES
130 .SS Source
131 When you compile the kernel,
132 it will automatically compile and link the vDSO code for you.
133 You will frequently find it under the architecture-specific directory:
134 .PP
135 find arch/$ARCH/ -name '*vdso*.so*' -o -name '*gate*.so*'
136 .\"
137 .SS vDSO names
138 The name of the vDSO varies across architectures.
139 It will often show up in things like glibc's
140 .BR ldd (1)
141 output.
142 The exact name should not matter to any code, so do not hardcode it.
143 .if t \{\
144 .ft CW
145 \}
146 .TS
147 l l.
148 user ABI vDSO name
149 _
150 aarch64 linux-vdso.so.1
151 arm linux-vdso.so.1
152 ia64 linux-gate.so.1
153 mips linux-vdso.so.1
154 ppc/32 linux-vdso32.so.1
155 ppc/64 linux-vdso64.so.1
156 s390 linux-vdso32.so.1
157 s390x linux-vdso64.so.1
158 sh linux-gate.so.1
159 i386 linux-gate.so.1
160 x86_64 linux-vdso.so.1
161 x86/x32 linux-vdso.so.1
162 .TE
163 .if t \{\
164 .in
165 .ft P
166 \}
167 .SS strace(1) and the vDSO
168 When tracing systems calls with
169 .BR strace (1),
170 symbols (system calls) that are exported by the vDSO will
171 .I not
172 appear in the trace output.
173 .SH ARCHITECTURE-SPECIFIC NOTES
174 The subsections below provide architecture-specific notes
175 on the vDSO.
176 .PP
177 Note that the vDSO that is used is based on the ABI of your user-space code
178 and not the ABI of the kernel.
179 Thus, for example,
180 when you run an i386 32-bit ELF binary,
181 you'll get the same vDSO regardless of whether you run it under
182 an i386 32-bit kernel or under an x86_64 64-bit kernel.
183 Therefore, the name of the user-space ABI should be used to determine
184 which of the sections below is relevant.
185 .SS ARM functions
186 .\" See linux/arch/arm/vdso/vdso.lds.S
187 .\" Commit: 8512287a8165592466cb9cb347ba94892e9c56a5
188 The table below lists the symbols exported by the vDSO.
189 .if t \{\
190 .ft CW
191 \}
192 .TS
193 l l.
194 symbol version
195 _
196 __vdso_gettimeofday LINUX_2.6 (exported since Linux 4.1)
197 __vdso_clock_gettime LINUX_2.6 (exported since Linux 4.1)
198 .TE
199 .if t \{\
200 .in
201 .ft P
202 \}
203 .PP
204 .\" See linux/arch/arm/kernel/entry-armv.S
205 .\" See linux/Documentation/arm/kernel_user_helpers.txt
206 Additionally, the ARM port has a code page full of utility functions.
207 Since it's just a raw page of code, there is no ELF information for doing
208 symbol lookups or versioning.
209 It does provide support for different versions though.
210 .PP
211 For information on this code page,
212 it's best to refer to the kernel documentation
213 as it's extremely detailed and covers everything you need to know:
214 .IR Documentation/arm/kernel_user_helpers.txt .
215 .SS aarch64 functions
216 .\" See linux/arch/arm64/kernel/vdso/vdso.lds.S
217 The table below lists the symbols exported by the vDSO.
218 .if t \{\
219 .ft CW
220 \}
221 .TS
222 l l.
223 symbol version
224 _
225 __kernel_rt_sigreturn LINUX_2.6.39
226 __kernel_gettimeofday LINUX_2.6.39
227 __kernel_clock_gettime LINUX_2.6.39
228 __kernel_clock_getres LINUX_2.6.39
229 .TE
230 .if t \{\
231 .in
232 .ft P
233 \}
234 .SS bfin (Blackfin) functions
235 .\" See linux/arch/blackfin/kernel/fixed_code.S
236 .\" See http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:fixed-code
237 As this CPU lacks a memory management unit (MMU),
238 it doesn't set up a vDSO in the normal sense.
239 Instead, it maps at boot time a few raw functions into
240 a fixed location in memory.
241 User-space applications then call directly into that region.
242 There is no provision for backward compatibility
243 beyond sniffing raw opcodes,
244 but as this is an embedded CPU, it can get away with things\(emsome of the
245 object formats it runs aren't even ELF based (they're bFLT/FLAT).
246 .PP
247 For information on this code page,
248 it's best to refer to the public documentation:
249 .br
250 http://docs.blackfin.uclinux.org/doku.php?id=linux\-kernel:fixed\-code
251 .SS mips functions
252 .\" See linux/arch/mips/vdso/vdso.ld.S
253 .PP
254 The table below lists the symbols exported by the vDSO.
255 .if t \{\
256 .ft CW
257 \}
258 .TS
259 l l.
260 symbol version
261 _
262 __kernel_gettimeofday LINUX_2.6 (exported since Linux 4.4)
263 __kernel_clock_gettime LINUX_2.6 (exported since Linux 4.4)
264 .TE
265 .if t \{\
266 .in
267 .ft P
268 \}
269 .PP
270 .br
271 .PP
272 .SS ia64 (Itanium) functions
273 .\" See linux/arch/ia64/kernel/gate.lds.S
274 .\" Also linux/arch/ia64/kernel/fsys.S and linux/Documentation/ia64/fsys.txt
275 The table below lists the symbols exported by the vDSO.
276 .if t \{\
277 .ft CW
278 \}
279 .TS
280 l l.
281 symbol version
282 _
283 __kernel_sigtramp LINUX_2.5
284 __kernel_syscall_via_break LINUX_2.5
285 __kernel_syscall_via_epc LINUX_2.5
286 .TE
287 .if t \{\
288 .in
289 .ft P
290 \}
291 .PP
292 The Itanium port is somewhat tricky.
293 In addition to the vDSO above, it also has "light-weight system calls"
294 (also known as "fast syscalls" or "fsys").
295 You can invoke these via the
296 .I __kernel_syscall_via_epc
297 vDSO helper.
298 The system calls listed here have the same semantics as if you called them
299 directly via
300 .BR syscall (2),
301 so refer to the relevant
302 documentation for each.
303 The table below lists the functions available via this mechanism.
304 .if t \{\
305 .ft CW
306 \}
307 .TS
308 l.
309 function
310 _
311 clock_gettime
312 getcpu
313 getpid
314 getppid
315 gettimeofday
316 set_tid_address
317 .TE
318 .if t \{\
319 .in
320 .ft P
321 \}
322 .SS parisc (hppa) functions
323 .\" See linux/arch/parisc/kernel/syscall.S
324 .\" See linux/Documentation/parisc/registers
325 The parisc port has a code page full of utility functions
326 called a gateway page.
327 Rather than use the normal ELF auxiliary vector approach,
328 it passes the address of
329 the page to the process via the SR2 register.
330 The permissions on the page are such that merely executing those addresses
331 automatically executes with kernel privileges and not in user space.
332 This is done to match the way HP-UX works.
333 .PP
334 Since it's just a raw page of code, there is no ELF information for doing
335 symbol lookups or versioning.
336 Simply call into the appropriate offset via the branch instruction,
337 for example:
338 .PP
339 ble <offset>(%sr2, %r0)
340 .if t \{\
341 .ft CW
342 \}
343 .TS
344 l l.
345 offset function
346 _
347 00b0 lws_entry
348 00e0 set_thread_pointer
349 0100 linux_gateway_entry (syscall)
350 0268 syscall_nosys
351 0274 tracesys
352 0324 tracesys_next
353 0368 tracesys_exit
354 03a0 tracesys_sigexit
355 03b8 lws_start
356 03dc lws_exit_nosys
357 03e0 lws_exit
358 03e4 lws_compare_and_swap64
359 03e8 lws_compare_and_swap
360 0404 cas_wouldblock
361 0410 cas_action
362 .TE
363 .if t \{\
364 .in
365 .ft P
366 \}
367 .SS ppc/32 functions
368 .\" See linux/arch/powerpc/kernel/vdso32/vdso32.lds.S
369 The table below lists the symbols exported by the vDSO.
370 The functions marked with a
371 .I *
372 are available only when the kernel is
373 a PowerPC64 (64-bit) kernel.
374 .if t \{\
375 .ft CW
376 \}
377 .TS
378 l l.
379 symbol version
380 _
381 __kernel_clock_getres LINUX_2.6.15
382 __kernel_clock_gettime LINUX_2.6.15
383 __kernel_datapage_offset LINUX_2.6.15
384 __kernel_get_syscall_map LINUX_2.6.15
385 __kernel_get_tbfreq LINUX_2.6.15
386 __kernel_getcpu \fI*\fR LINUX_2.6.15
387 __kernel_gettimeofday LINUX_2.6.15
388 __kernel_sigtramp_rt32 LINUX_2.6.15
389 __kernel_sigtramp32 LINUX_2.6.15
390 __kernel_sync_dicache LINUX_2.6.15
391 __kernel_sync_dicache_p5 LINUX_2.6.15
392 .TE
393 .if t \{\
394 .in
395 .ft P
396 \}
397 .PP
398 The
399 .B CLOCK_REALTIME_COARSE
400 and
401 .B CLOCK_MONOTONIC_COARSE
402 clocks are
403 .I not
404 supported by the
405 .I __kernel_clock_getres
406 and
407 .I __kernel_clock_gettime
408 interfaces;
409 the kernel falls back to the real system call.
410 .SS ppc/64 functions
411 .\" See linux/arch/powerpc/kernel/vdso64/vdso64.lds.S
412 The table below lists the symbols exported by the vDSO.
413 .if t \{\
414 .ft CW
415 \}
416 .TS
417 l l.
418 symbol version
419 _
420 __kernel_clock_getres LINUX_2.6.15
421 __kernel_clock_gettime LINUX_2.6.15
422 __kernel_datapage_offset LINUX_2.6.15
423 __kernel_get_syscall_map LINUX_2.6.15
424 __kernel_get_tbfreq LINUX_2.6.15
425 __kernel_getcpu LINUX_2.6.15
426 __kernel_gettimeofday LINUX_2.6.15
427 __kernel_sigtramp_rt64 LINUX_2.6.15
428 __kernel_sync_dicache LINUX_2.6.15
429 __kernel_sync_dicache_p5 LINUX_2.6.15
430 .TE
431 .if t \{\
432 .in
433 .ft P
434 \}
435 .PP
436 The
437 .B CLOCK_REALTIME_COARSE
438 and
439 .B CLOCK_MONOTONIC_COARSE
440 clocks are
441 .I not
442 supported by the
443 .I __kernel_clock_getres
444 and
445 .I __kernel_clock_gettime
446 interfaces;
447 the kernel falls back to the real system call.
448 .SS s390 functions
449 .\" See linux/arch/s390/kernel/vdso32/vdso32.lds.S
450 The table below lists the symbols exported by the vDSO.
451 .if t \{\
452 .ft CW
453 \}
454 .TS
455 l l.
456 symbol version
457 _
458 __kernel_clock_getres LINUX_2.6.29
459 __kernel_clock_gettime LINUX_2.6.29
460 __kernel_gettimeofday LINUX_2.6.29
461 .TE
462 .if t \{\
463 .in
464 .ft P
465 \}
466 .SS s390x functions
467 .\" See linux/arch/s390/kernel/vdso64/vdso64.lds.S
468 The table below lists the symbols exported by the vDSO.
469 .if t \{\
470 .ft CW
471 \}
472 .TS
473 l l.
474 symbol version
475 _
476 __kernel_clock_getres LINUX_2.6.29
477 __kernel_clock_gettime LINUX_2.6.29
478 __kernel_gettimeofday LINUX_2.6.29
479 .TE
480 .if t \{\
481 .in
482 .ft P
483 \}
484 .SS sh (SuperH) functions
485 .\" See linux/arch/sh/kernel/vsyscall/vsyscall.lds.S
486 The table below lists the symbols exported by the vDSO.
487 .if t \{\
488 .ft CW
489 \}
490 .TS
491 l l.
492 symbol version
493 _
494 __kernel_rt_sigreturn LINUX_2.6
495 __kernel_sigreturn LINUX_2.6
496 __kernel_vsyscall LINUX_2.6
497 .TE
498 .if t \{\
499 .in
500 .ft P
501 \}
502 .SS i386 functions
503 .\" See linux/arch/x86/vdso/vdso32/vdso32.lds.S
504 The table below lists the symbols exported by the vDSO.
505 .if t \{\
506 .ft CW
507 \}
508 .TS
509 l l.
510 symbol version
511 _
512 __kernel_sigreturn LINUX_2.5
513 __kernel_rt_sigreturn LINUX_2.5
514 __kernel_vsyscall LINUX_2.5
515 .\" Added in 7a59ed415f5b57469e22e41fc4188d5399e0b194 and updated
516 .\" in 37c975545ec63320789962bf307f000f08fabd48.
517 __vdso_clock_gettime LINUX_2.6 (exported since Linux 3.15)
518 __vdso_gettimeofday LINUX_2.6 (exported since Linux 3.15)
519 __vdso_time LINUX_2.6 (exported since Linux 3.15)
520 .TE
521 .if t \{\
522 .in
523 .ft P
524 \}
525 .SS x86_64 functions
526 .\" See linux/arch/x86/vdso/vdso.lds.S
527 The table below lists the symbols exported by the vDSO.
528 All of these symbols are also available without the "__vdso_" prefix, but
529 you should ignore those and stick to the names below.
530 .if t \{\
531 .ft CW
532 \}
533 .TS
534 l l.
535 symbol version
536 _
537 __vdso_clock_gettime LINUX_2.6
538 __vdso_getcpu LINUX_2.6
539 __vdso_gettimeofday LINUX_2.6
540 __vdso_time LINUX_2.6
541 .TE
542 .if t \{\
543 .in
544 .ft P
545 \}
546 .SS x86/x32 functions
547 .\" See linux/arch/x86/vdso/vdso32.lds.S
548 The table below lists the symbols exported by the vDSO.
549 .if t \{\
550 .ft CW
551 \}
552 .TS
553 l l.
554 symbol version
555 _
556 __vdso_clock_gettime LINUX_2.6
557 __vdso_getcpu LINUX_2.6
558 __vdso_gettimeofday LINUX_2.6
559 __vdso_time LINUX_2.6
560 .TE
561 .if t \{\
562 .in
563 .ft P
564 \}
565 .SS History
566 The vDSO was originally just a single function\(emthe vsyscall.
567 In older kernels, you might see that name
568 in a process's memory map rather than "vdso".
569 Over time, people realized that this mechanism
570 was a great way to pass more functionality
571 to user space, so it was reconceived as a vDSO in the current format.
572 .SH SEE ALSO
573 .BR syscalls (2),
574 .BR getauxval (3),
575 .BR proc (5)
576 .PP
577 The documents, examples, and source code in the Linux source code tree:
578 .PP
579 .in +4n
580 .EX
581 Documentation/ABI/stable/vdso
582 Documentation/ia64/fsys.txt
583 Documentation/vDSO/* (includes examples of using the vDSO)
584
585 find arch/ -iname '*vdso*' -o -iname '*gate*'
586 .fi
587 .in