ldd shows no location after arrow; library does not exist on system

Question

I want to create a chroot environment that has access to hand-picked programs but is completely isolated from the rest of the system.

I created three folders in this chroot folder: bin, lib, lib64. I then copied an executable, in this case /bin/bash into bin. ldd /bin/bash shows this output:

linux-vdso.so.1 =>  (0x00007ffff01f6000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f35ed501000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f35ed2fd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f35ecf33000)
/lib64/ld-linux-x86-64.so.2 (0x00007f35ed72a000)

I can copy all of these libraries, except linux-vdso.so.1. If I sudo find / -name "linux-vdso.so.1" I get no output.

What should I do now?

Solution 1

The VDSO is special, it is directly provided by the kernel.

You see that it has addresses, even if it doesn't have a file name, so it got mapped fine. You don't need to do anything to get the VDSO in the chroot.

The kernel VDSO is a collection of kernel functions that don't always require a mode switch, e.g. reading exact timers is handled by the rdtsc assembler instruction on processors that support it, and by a kernel syscalls on processors that don't. If this were a normal system call, modern processors would have to deal with the syscall overhead for a single non-privileged assembler instruction, and if rdtsc was always inlined, programs would no longer run on older machines.

Solution 2

You should try running your programs ;-)

linux-vdso.so.1 is a virtual library that is automatically mapped in the address space of a process by the kernel, see vdso(7). It does not exist in the filesystem.