Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#239 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
rust

調査の方向性

まず、最初の512GiBの予約箇所の周辺にある src/binary/level_4_entries.rs と、コンテキストスイッチおよび GDT のマッピング箇所の周辺にある src/binary/mod.rs を読みます。kernel のページテーブルと Mappings がどのように構築されるかを追跡します。完了条件は、bootloader の部分が kernel のアドレス空間に残されておらず、一時的なコンテキストスイッチ用マッピングが処理され、GDT の位置が公開されるか設定可能になっていることです。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Rust
スター
1.7k
フォーク
240
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rust-osdev/bootloader のほかの issue

rust-osdev/bootloader の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。