vdso와 vsyscall은 무엇입니까?

Question 1

나는했다 sudo cat /proc/1/maps -vv

출력을 이해하려고 시도하고 있는데 예상대로 메모리 매핑 세그먼트에 많은 공유 라이브러리가 매핑되는 것을 볼 수 있습니다.

7f3c00137000-7f3c00179000 r-xp 00000000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c00179000-7f3c00379000 ---p 00042000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c00379000-7f3c0037a000 r--p 00042000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c0037a000-7f3c0037b000 rw-p 00043000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c0037b000-7f3c00383000 r-xp 00000000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00383000-7f3c00583000 ---p 00008000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00583000-7f3c00584000 r--p 00008000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00584000-7f3c00585000 rw-p 00009000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00585000-7f3c0059b000 r-xp 00000000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0
7f3c0059b000-7f3c0079b000 ---p 00016000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0
7f3c0079b000-7f3c0079c000 r--p 00016000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0

끝을 향해 다음과 같은 것이 있습니다.

7f3c0165b000-7f3c0177e000 rw-p 00000000 00:00 0                          [heap]
7fff97863000-7fff97884000 rw-p 00000000 00:00 0                          [stack]
7fff97945000-7fff97946000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

무엇 vdso을 vsyscall의미합니까? vsyscall은 메모리의 커널 부분입니까? 누군가가 문제에 대해 약간의 빛을 던질 수 있다면 좋을 것입니다.

Question 2

vsyscall 및 VDSO 세그먼트는 리눅스에서 특정 시스템 호출을 가속화하는 데 사용되는 두 가지 메커니즘이다. 예를 들어, gettimeofday일반적으로이 메커니즘을 통해 호출됩니다. 도입 된 첫 번째 메커니즘은 vsyscall으로 , 시스템 호출 오버 헤드를 줄이기 위해 실행하는 데 실제 수준의 권한이 필요하지 않은 특정 시스템 호출을 실행하는 방법으로 추가되었습니다. 이전 예제에 따라 gettimeofday해야 할 일은 커널의 현재 시간을 읽는 것입니다. gettimeofday약간의 오버 헤드도 신경 쓰는 지점까지 자주 호출 하는 (예 : 타임 스탬프 생성) 애플리케이션이 있습니다 . 이 문제를 해결하기 위해 커널은 현재 시간과 빠른 속도를 포함하는 페이지를 사용자 공간에 매핑합니다.gettimeofday구현 (즉, vsyscall에 절약 된 시간을 읽는 함수 ). 이 가상 시스템 호출을 사용하여 C 라이브러리는 gettimeofday일반적으로 고전적인 시스템 호출 모델 INT 0x80또는 에서 도입 된 커널 공간과 사용자 공간 간의 컨텍스트 전환으로 인한 오버 헤드가없는 빠른 속도 를 제공 할 수 있습니다 SYSCALL.

그러나이 vsyscall 메커니즘에는 몇 가지 제한이 있습니다. 할당 된 메모리는 작고 4 개의 시스템 호출 만 허용하며, 더 중요하고 심각한 것은 vsyscall 페이지의 위치가 다음과 같기 때문에 vsyscall 페이지가 각 프로세스에서 동일한 주소에 정적으로 할당 된다는 것 입니다. 커널 ABI에 못 박혔습니다. vsyscall의 이러한 정적 할당은 Linux에서 일반적으로 사용되는 메모리 공간 무작위 화로 인한 이점을 손상시킵니다. 공격자는 스택 오버플로를 악용하여 애플리케이션을 손상시킨 후 vsyscall 에서 시스템 호출을 호출 할 수 있습니다.임의의 매개 변수가있는 페이지. 그가 필요로하는 것은 시스템 호출의 주소이며 정적으로 할당되기 때문에 쉽게 예측할 수 있습니다 (다른 응용 프로그램에서도 명령을 다시 실행하려고하면 vsyscall 의 주소가 변경되지 않음을 알 수 있습니다). 이러한 유형의 공격을 막기 위해 vsyscall 페이지의 위치를 제거하거나 적어도 무작위로 지정하는 것이 좋습니다. 안타깝게도 응용 프로그램은 해당 페이지의 존재 여부와 정확한 주소에 따라 달라 지므로 아무것도 할 수 없습니다.

이 보안 문제는 고정 주소의 모든 시스템 호출 명령을 특수 트랩 명령으로 대체하여 해결되었습니다. vsyscall 페이지 를 호출하려는 응용 프로그램 은 커널에 트랩되어 커널 공간에서 원하는 가상 시스템 호출을 에뮬레이트합니다. 그 결과 처음에 커널 시스템 호출을 피하기 위해 거기에 놓인 가상 시스템 호출을 에뮬레이트하는 커널 시스템 호출입니다. 그 결과 실행 시간이 더 오래 걸리지 만 결정적으로 기존 ABI를 깨지 않는 vsyscall 이 발생합니다. 어쨌든 속도 저하는 애플리케이션이 vDSO 대신 vsyscall 페이지 를 사용하려는 경우에만 표시됩니다 .

VDSO는 그 한계를 극복하면서 vsyscall와 동일한 기능을 제공합니다. vDSO (Virtual Dynamically Linked Shared Objects)는 사용자 공간에 할당 된 메모리 영역으로, 사용자 공간에서 일부 커널 기능을 안전한 방식으로 노출합니다. 이는 .NET Framework로 인한 보안 위협을 해결하기 위해 도입되었습니다 vsyscall. vDSO는 동적으로 할당되어 보안 문제를 해결하고 4 개 이상의 시스템 호출을 가질 수 있습니다. VDSO의 링크는 glibc는 라이브러리를 통해 제공됩니다. 링커는 glibc에 링크를 것 VDSO의 이러한 루틴 수반 가지고 제공 기능 VDSO에 같은 버전, gettimeofday. 프로그램이 실행될 때 커널에 vDSO 가없는 경우 지원, 전통적인 syscall이 만들어 질 것입니다.

크레딧 및 유용한 링크 :

Question 3

이제 새 커널에서 vDSO"안전한"시스템 호출에만 사용되는 것이 아니라 시스템에서 시스템 호출을 호출하는 데 선호되는 시스템 호출 메커니즘을 결정하는 데 사용됩니다.