2017-12-20 88 views
5

Mục tiêu của tôi là truy cập IDT từ mô-đun hạt nhân MacOS.Địa chỉ trả về mã vạch SIDT cho cấu trúc IDT không đúng định dạng

Tôi đang chạy macOS 10.13.2 trong VMFusion 10.0.1 và có vẻ như lệnh lắp ráp sidt trỏ tới cấu trúc bảng bị hỏng.

Mã opcode này sẽ trả về địa chỉ cho "Bảng mô tả ngắt" giữ bộ mô tả cho từng ngắt.

Mỗi con trỏ chứa gián đoạn cho chức năng gọi lại sẽ được gọi khi một gián đoạn cụ thể được gọi.

Ví dụ: đây là 2 trình mô tả ngắt trỏ tới các cuộc gọi lại hợp lệ từ phần __TEXT của nhân trong các phiên bản cũ hơn trước đó.

  • điểm int3 để idt64_int3
  • int80 điểm để idt64_unix_scall

vv ...

Đối với một số lý do, bắt đầu từ cao Sierra 10.13.2, phạm vi bộ nhớ sidt trở lại điều đó không không chứa các con trỏ hợp lệ (tất cả nằm ngoài ranh giới của phần hạt nhân __TEXT). có lẽ có một cách khác để lấy con trỏ bảng?

đây là mã của tôi nguồn cho việc tìm kiếm con trỏ IDT:

unsigned char idt_out[10]; 
__asm__ volatile ("sidt %0": "=m" (idt_out)); 

// skip the first 2 bytes as they are not part of the address 
uint64_t idt_address = *((unsigned long long *)(idt_out+2)); 
printf("idt address is %llx \n", idt_address); 

int80_desc = (struct descriptor_idt*)(idt_address + sizeof(struct idt_desc)*0x80); 
int80_address = (mach_vm_address_t)(((unsigned long)int80_desc->offset_high << 32) + ((unsigned int)int80_desc->offset_middle << 16) + int80_descriptor->offset_low); // this should point to idt64_unix_scall 
+1

'sidt' trả về địa chỉ thực thay vì địa chỉ ảo. Bạn có chắc chắn dịch địa chỉ ảo sang địa chỉ ảo trước khi cố gắng hiểu nội dung của nó không? – fuz

+0

Tôi đang cố gắng truy cập idt từ mô-đun hạt nhân để có, và khi chạy cùng mã từ phiên bản cũ hơn của macOS, và nó hoạt động hoàn hảo. – Zohar81

+1

Ngay cả trong một địa chỉ mô-đun hạt nhân là ảo. Không có cách nào thực sự chuyển đổi địa chỉ sang địa chỉ ảo. – fuz

Trả lời

0

Rõ ràng, lý do cho sidt ngừng làm việc là có chủ ý và một phần của việc sửa chữa Meltdown.

Đó là tất cả những gì tôi quản lý để tìm hiểu cho đến giờ, nếu có ai có thêm manh mối về lý luận, hãy khai sáng cho chúng tôi.

+0

Bạn có chắc chắn đó là một phần của giải pháp khắc phục sự cố Meltdown và không phải là giải pháp Spectre? Một hạt nhân có thể tự bảo vệ hoàn toàn khỏi Meltdown bằng cách không bao giờ rời khỏi bộ nhớ hạt nhân được ánh xạ (tùy thuộc vào bit U/S được thiết lập để bảo vệ) khi chạy mã không gian người dùng. Tôi không thấy IDT có liên quan gì đến nó. Hoặc là một cái gì đó để làm với máy ảo, chứ không phải là bản vá lỗi hạt nhân OS X? –

+0

Xin chào, từ những gì tôi biết như là một thực tế (mà không đảo ngược cho đến nay), là bản vá trong 10.13.2 rõ ràng cho thấy hành vi IDT mới .. Tôi có thể giả định từ thời điểm phát hành 10.13.2 rằng thay đổi này đến để cải thiện tách bộ nhớ giữa các ứng dụng hạt nhân và người dùng vì opcode này không yêu cầu bất kỳ sự cho phép đặc biệt nào. nó có vẻ hợp lý. Tôi ước tôi có thể hiểu chính xác cách thức hoạt động của IDT. nếu nó được quản lý bởi hạt nhân (và không phải là phần cứng) vì vậy tôi đoán họ bằng cách nào đó thay đổi truy cập vào các callbacks ngắt để nó sẽ không được tiếp xúc trong anyway từ người sử dụng không gian. – Zohar81

+0

Có thể đó là cho Meltdown. Tôi nghĩ rằng IDT phải được ánh xạ để các gián đoạn hoạt động (bao gồm cả khi mã không gian người dùng đang thực thi), do đó, không gian người dùng có thể đọc nó với Meltdown. Điều này có thể làm lộ ra con trỏ vào hạt nhân, đánh bại ASLR của hạt nhân. Vì vậy, có lẽ họ làm một số thủ đoạn. Giống như có thể thêm một mức độ bất định. Trong câu hỏi của bạn, bạn nói cấu trúc là "bị hỏng", nhưng chắc chắn nó phải trỏ đến đâu đó có con trỏ tới các trình xử lý. (Trừ khi có một số cấp độ thêm của VM trickery xảy ra và nó không thực sự thi đua 'sidt' bên trong VM, như Ross đề nghị.) –

Các vấn đề liên quan