Vdso và vsyscall là gì?

Question 1

tôi đã làm sudo cat /proc/1/maps -vv

Tôi đang cố gắng hiểu kết quả đầu ra thì có thể thấy rất nhiều thư viện được chia sẻ được ánh xạ tới phân đoạn ánh xạ bộ nhớ như mong đợi.

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

Về cuối, có một cái gì đó giống như

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]

Không gì vdsovà vsyscallnghĩa là gì? vsyscall có phải là phần nhân của bộ nhớ không? Sẽ thật tuyệt nếu ai đó có thể làm sáng tỏ vấn đề này.

Question 2

Các vsyscall và vDSO phân đoạn là hai cơ chế sử dụng để thúc đẩy các cuộc gọi hệ thống nhất định trong Linux. Ví dụ, gettimeofdaythường được gọi thông qua cơ chế này. Cơ chế đầu tiên được giới thiệu là vsyscall , được thêm vào như một cách để thực hiện các lệnh gọi hệ thống cụ thể mà không cần bất kỳ mức đặc quyền thực sự nào để chạy nhằm giảm chi phí cuộc gọi hệ thống. Theo ví dụ trước, tất cả những gì gettimeofdaycần làm là đọc thời gian hiện tại của kernel. Có những ứng dụng gọi gettimeofdaythường xuyên (ví dụ: để tạo dấu thời gian), đến mức họ quan tâm đến cả một chút chi phí. Để giải quyết mối lo ngại này, hạt nhân ánh xạ vào không gian người dùng một trang chứa thời gian hiện tại vàgettimeofdaytriển khai (tức là chỉ một chức năng đọc thời gian được lưu vào vsyscall ). Sử dụng lệnh gọi hệ thống ảo này, thư viện C có thể cung cấp một tốc độ nhanh gettimeofdaymà không có chi phí được giới thiệu bởi chuyển đổi ngữ cảnh giữa không gian nhân và không gian người dùng thường được giới thiệu bởi mô hình gọi hệ thống cổ điển INT 0x80hoặc SYSCALL.

Tuy nhiên, cơ chế vsyscall này có một số hạn chế: bộ nhớ được cấp phát nhỏ và chỉ cho phép 4 lệnh gọi hệ thống, và quan trọng và nghiêm trọng hơn, trang vsyscall được cấp phát tĩnh cho cùng một địa chỉ trong mỗi quá trình, vì vị trí của trang vsyscall là đóng đinh trong hạt nhân ABI. Việc phân bổ tĩnh vsyscall này ảnh hưởng đến lợi ích được giới thiệu bởi ngẫu nhiên không gian bộ nhớ thường được sử dụng bởi Linux. Kẻ tấn công, sau khi xâm phạm ứng dụng bằng cách khai thác tràn ngăn xếp, có thể gọi hệ thống từ vsyscalltrang với các tham số tùy ý. Tất cả những gì anh ta cần là địa chỉ của lệnh gọi hệ thống, có thể dễ dàng đoán được vì nó được cấp phát tĩnh (nếu bạn cố gắng chạy lại lệnh của mình ngay cả với các ứng dụng khác nhau, bạn sẽ nhận thấy rằng địa chỉ của vsyscall không thay đổi). Sẽ rất tuyệt nếu loại bỏ hoặc ít nhất là ngẫu nhiên vị trí của trang vsyscall để ngăn chặn kiểu tấn công này. Thật không may, các ứng dụng phụ thuộc vào sự tồn tại và địa chỉ chính xác của trang đó, vì vậy không thể làm gì được.

Vấn đề bảo mật này đã được giải quyết bằng cách thay thế tất cả các lệnh gọi hệ thống tại các địa chỉ cố định bằng một lệnh bẫy đặc biệt. Một ứng dụng đang cố gắng gọi vào trang vsyscall sẽ bẫy vào hạt nhân, sau đó sẽ mô phỏng lệnh gọi hệ thống ảo mong muốn trong không gian hạt nhân. Kết quả là một lệnh gọi hệ thống hạt nhân mô phỏng một lệnh gọi hệ thống ảo được đặt ở đó để tránh lệnh gọi hệ thống hạt nhân ngay từ đầu. Kết quả là một vsyscall mất nhiều thời gian hơn để thực thi nhưng quan trọng là không phá vỡ ABI hiện có. Trong mọi trường hợp, sự chậm lại sẽ chỉ được nhìn thấy nếu ứng dụng đang cố gắng sử dụng trang vsyscall thay vì vDSO .

Các vDSO cung cấp chức năng tương tự như các vsyscall, trong khi việc khắc phục những hạn chế của nó. VDSO (Các đối tượng được chia sẻ được liên kết động ảo) là một vùng bộ nhớ được cấp phát trong không gian người dùng để hiển thị một số chức năng của hạt nhân tại không gian người dùng một cách an toàn. Điều này đã được giới thiệu để giải quyết các mối đe dọa bảo mật do vsyscall. VDSO được cấp phát động giúp giải quyết các vấn đề về bảo mật và có thể có nhiều hơn 4 lệnh gọi hệ thống. Các liên kết vDSO được cung cấp thông qua thư viện glibc. Trình liên kết sẽ liên kết trong chức năng glibc vDSO , miễn là quy trình đó có phiên bản vDSO đi kèm , chẳng hạn như gettimeofday. Khi chương trình của bạn thực thi, nếu hạt nhân của bạn không có vDSO hỗ trợ, một cuộc gọi syscall truyền thống sẽ được thực hiện.

Tín dụng và các liên kết hữu ích:

Question 3

Tôi chỉ muốn nói thêm rằng bây giờ trong các hạt nhân mới, vDSOkhông chỉ được sử dụng cho các cuộc gọi tổng hợp "an toàn" mà nó được sử dụng để quyết định cơ chế cuộc gọi tổng hợp nào là phương pháp ưu tiên để gọi một cuộc gọi tổng hợp trên hệ thống.