Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

don't leave parts of the bootloader in the kernel's address space

Đang mở
  • Có gì không ổn?
#239 7 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
rust
Lĩnh vực
operating-systems

Hướng nghiên cứu

Bắt đầu bằng cách đọc src/binary/level_4_entries.rs xung quanh phần dành riêng 512GiB đầu tiên và src/binary/mod.rs xung quanh việc chuyển đổi ngữ cảnh và các ánh xạ GDT. Theo dõi cách page table của kernel và Mappings được xây dựng; hoàn thành có nghĩa là các phần của bootloader không còn bị để lại trong không gian địa chỉ của kernel, ánh xạ chuyển đổi ngữ cảnh tạm thời được xử lý, và vị trí của GDT được công khai hoặc có thể cấu hình.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

While implementing finer granular ASLR I came across this comment:
https://github.com/rust-osdev/bootloader/blob/ac46d0455b41c11e5d316348d068df1c495ce0af/src/binary/level_4_entries.rs#L40
We mark the first 512GiB of the address space as unusable for dynamically generated addresses. I think we do this because we identity map the context switch code into kernel memory and this code most likely resides within the first 512GiB of the address space:
https://github.com/rust-osdev/bootloader/blob/a445433010960ec5d8a8b94a85fcac16a00489b5/src/binary/mod.rs#L166-L181

This causes a number of (admittedly small and unlikely) problems:

  • The identity mapped pages could overlap with the kernel or other mappings
  • We don't expose the identity mapped addresses to the kernel in Mappings
  • An attacker could make use of the identity mapped pages to defeat ASLR
  • We mark so a lot of usable memory as unusable and because of that we can't check for overlaps because there would be a lot of false positives. We currently just ignore overlaps.

We could probably work around those problems while still mapping parts of the bootloader into the kernel's address space, but I'd like to propose another solution: We use another very short lived page table to do the context switch. This page table would only map a few pages containing code that switches to the kernel's page table. Importantly, we would set the page table up in such a way that the kernel's entrypoint is just after the page table switch instruction, so we don't have to use any code to jump to the kernel, it would simply be the next instruction.
I don't think we could reliably map such code into the bootloader's address space because we'd have to map the code just before the kernel's entrypoint which could be close to bootloader's code, so that's why I want to use a short-lived page table.

We also identity map a GDT into the kernel's address space:
https://github.com/rust-osdev/bootloader/blob/a445433010960ec5d8a8b94a85fcac16a00489b5/src/binary/mod.rs#L183-L193
We should probably make the GDT's location configurable and expose it in Mappings.

I'd be happy to work on a pr for this.

Ngôn ngữ chính
Rust
Star
1.7k
Fork
240
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của rust-osdev/bootloader

Tất cả issue của rust-osdev/bootloader

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.