3 ms·

Some BSDs (and Zircon/Fuchsia) block any syscall instructions that don't originate from inside the vDSO. Which means the only way to do them is to go through li

by chc4 4y ago

Some BSDs (and Zircon/Fuchsia) block any syscall instructions that don't originate from inside the vDSO. Which means the only way to do them is to go through libc (well, the parts of libc that are provided by the vDSO, but semantics). https://fuchsia.dev/fuchsia-src/concepts/kernel/vdso https://fuchsia.dev/fuchsia-src/concepts/kernel/vdso mentions this, for example.

erichocean 4y ago
I'm almost 100% certain that anyone can directly call Fuchsia's vDSO syscalls without linking in any form of libc. It's not at all like the macOS situation.
- matheusmoreira 4y ago
  vDSOs are essentially pre-linked C libraries though. On Linux they are normal shared objects with the C ABI. They can even be found in the file system with names like linux-vdso.so.1.
  - account42 4y ago
    vDSOs are however an API provided by the kernel (hence the v, they aren't separate .so files that you need to load, even on Linux)
    - matheusmoreira 4y ago
      The vDSO is a normal .so file that gets built alongside the Linux kernel. The .so file is installed on the file system like any other library. When mapped into the process address space, it's just a normal ELF image. The functions all conform to the normal C ABI for the platform. It's true that we don't need to load the vDSO into the address space of the process since the kernel does it for us. We do need to manually link the vDSO functions though: the kernel uses the auxiliary vector to pass the address of the vDSO ELF image to the process, allowing it to parse the ELF header and find the addresses of the functions. In most cases, the libc will do this while initializing itself prior to calling main.
      - account42 4y ago
        > The .so file is installed on the file system like any other library. Nope, it is built into the kernel image - at least on my system, but there doesn't seem to be a config option to disable that. > When mapped into the process address space, it's just a normal ELF image. The functions all conform to the normal C ABI for the platform. That's purely for convencience because it allows ASLR for the vDSO and there is no point in making it a new ad-hoc format if every C library already needs an ELF dynamic linker - if the vDSO was a thing before ELF it would surely have a different format. > We do need to manually link the vDSO functions though: the kernel uses the auxiliary vector to pass the address of the vDSO ELF image to the process, allowing it to parse the ELF header and find the addresses of the functions. In most cases, the libc will do this while initializing itself prior to calling main. You need to look up the entry points in the vDSO before you can call them but that is really no different than checking the kernel version before deciding which syscalls to invoke. And no, the vDSO is not loaded like any other .so - it is very much a special case [0] even if the libc ends up reusing some of the normal .so code and structures. For example, it needs to be loaded even for statically linked binaries [1]. [0] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sysdeps/unix/sysv/linux/dl-vdso.h;h=8611488accfb02e037109500ddae6053534c0800;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sys... [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1e8bdc3a2b3e8d6e26efd14d44ae71d21d8366fe https://sourceware.org/git/?p=glibc.git;a=commit;h=1e8bdc3a2...

by chc4 4y ago

erichocean 4y ago

I'm almost 100% certain that anyone can directly call Fuchsia's vDSO syscalls without linking in any form of libc. It's not at all like the macOS situation.

matheusmoreira 4y ago
vDSOs are essentially pre-linked C libraries though. On Linux they are normal shared objects with the C ABI. They can even be found in the file system with names like linux-vdso.so.1.
- account42 4y ago
  vDSOs are however an API provided by the kernel (hence the v, they aren't separate .so files that you need to load, even on Linux)
  - matheusmoreira 4y ago
    The vDSO is a normal .so file that gets built alongside the Linux kernel. The .so file is installed on the file system like any other library. When mapped into the process address space, it's just a normal ELF image. The functions all conform to the normal C ABI for the platform. It's true that we don't need to load the vDSO into the address space of the process since the kernel does it for us. We do need to manually link the vDSO functions though: the kernel uses the auxiliary vector to pass the address of the vDSO ELF image to the process, allowing it to parse the ELF header and find the addresses of the functions. In most cases, the libc will do this while initializing itself prior to calling main.
    - account42 4y ago
      > The .so file is installed on the file system like any other library. Nope, it is built into the kernel image - at least on my system, but there doesn't seem to be a config option to disable that. > When mapped into the process address space, it's just a normal ELF image. The functions all conform to the normal C ABI for the platform. That's purely for convencience because it allows ASLR for the vDSO and there is no point in making it a new ad-hoc format if every C library already needs an ELF dynamic linker - if the vDSO was a thing before ELF it would surely have a different format. > We do need to manually link the vDSO functions though: the kernel uses the auxiliary vector to pass the address of the vDSO ELF image to the process, allowing it to parse the ELF header and find the addresses of the functions. In most cases, the libc will do this while initializing itself prior to calling main. You need to look up the entry points in the vDSO before you can call them but that is really no different than checking the kernel version before deciding which syscalls to invoke. And no, the vDSO is not loaded like any other .so - it is very much a special case [0] even if the libc ends up reusing some of the normal .so code and structures. For example, it needs to be loaded even for statically linked binaries [1]. [0] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sysdeps/unix/sysv/linux/dl-vdso.h;h=8611488accfb02e037109500ddae6053534c0800;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sys... [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1e8bdc3a2b3e8d6e26efd14d44ae71d21d8366fe https://sourceware.org/git/?p=glibc.git;a=commit;h=1e8bdc3a2...