osdev-jp

OS開発・低レイヤの知識はまだまだ浅いです。OS開発ではあまり使いませんがC#が得意です。今はOS開発の為の準備を進めています。 Takym は「たかやま」と読みます。

リンク

OSに関係のあるプロジェクト

名前	プロジェクトページ	説明	備考/状態
OSDeveloper	GitHub	OSの開発ができるIDEになる予定でした。OSを自作したら別の形を模索して再開するかもしれません。	開発中断

日本の低レイヤコミュニティ・OS開発プロジェクト

少しまとめてみましたが、完全では無いです。

osdev-jp
OSASK計画
Mona OS
- Mona OS Wiki
- Monacoin とは関係無い。両方とも2ch発祥。
Kozos
はりぼて友の会
- web archive
その他日本産Linux等：Wikipedia 日本のLinux開発
- web archive ***

いずれ日本語に翻訳したい資料

UEFI
- UEFI 2.9
Intel SDM

自分用のメモ

低レイヤに関する自分用のメモです。Slack等で流れた会話を自分なりに要約しています。間違い等がありましたら、教えてください。

このメモで特に指定が無ければ、CPUはx86_32かx86_64を指します。

EDK II (vUDK2018) on Windows 10

Windows 10 (1709 ビルド 16299.1087) での EDK II (vUDK2018) の自分の環境では上手くできたインストール方法です。

vUDK2018 からツールキットをダウンロードする。
NASM をインストールする。(インストール先のパスは空白を含めると上手く読み込めなくなる)
- 例: C:\nasm\
環境変数の NASM_PREFIX と PATH に NASM のインストール先のディレクトリを追加する。
Microsoft Visual Studio 2017 の「C++ によるデスクトップ開発」をインストールする。
Cygwin か MinGW をインストールする？ (必要かどうかは試していません。)
ダウンロードしておいたツールキットを適当なディレクトリに配置する。
- ここでは便宜的に %WORKSPACE% 呼ぶ。
%WORKSPACE%\BaseTools\Bin\Win32 内に edk2-BaseTools-win32 からダウンロードしてきたツールを入れる。
edksetup.bat を実行。
%WORKSPACE%\Conf\tools_def.txt から /WX を全て削除。
%WORKSPACE%\Conf\target.txt の TOOL_CHAIN_TAG を VS2017 に変更する。
build してテストする。 ***

巨大なコードの読み方

GNU GLOBAL：GNU製のコードリーディングを手伝ってくれるツール。タグ付けしてくれるのが特徴。
カーネルソースツアー
Vimでコードリーディング ***

GDTのGビット

GDT の G-bit フラグが立っている場合、4KB(=0x1000bytes)単位で設定できる様になる。
リミットに特定の値 a を設定した場合は、範囲は a + 0x0FFF までとなる。
例えばリミットに 0x54321 を設定したい場合は 0x54 を書き込むだけで良い。
- ただし、範囲は 0x54FFF までとなり、使わない 3294 バイト分の領域まで確保されてしまう。

Haribote OS では以下の様に設定されている。

(中略)
if (limit > 0xFFFFF) {
  ar    |= 0x8000; // G-bit = 1
  limit /= 0x1000;
}
(中略)

VGAのカラーパレット

取得する場合は0x03C7にパレット番号を指定して、0x03C9で読み込む。(RGBの順番で1バイトずつ)
設定する場合は0x03C8でパレット番号を指定して、0x03C9で書き込む。(RGBの順番で1バイトずつ)
パレット番号は0～255の8ビットまで、RGBの一つの要素は0～63の6ビットまで。

予めカラーパレットに以下の様に設定すれば、8ビットでIIRRGGBBの様に指定できる。(Iで明暗度(Intensity)を指定できる)

(中略)
int i, j;
io_out8(0x03C8, 0);
for (i = 0; i < 256; ++i) {
  j = (((i >> 6) & 3) + 1) * 4; // IIのビットを取得、0b00の時は4、0b01の時は8、0b10の時は12、0b11の時は16
  io_out8(0x03C9, (((i >> 4) & 3) + 1) * j - 1); // RRのビットを取得して書き込み、1～4の値にjを掛けて1を引く
  io_out8(0x03C9, (((i >> 2) & 3) + 1) * j - 1); // GGのビットを取得して書き込み、1～4の値にjを掛けて1を引く
  io_out8(0x03C9, (((i >> 0) & 3) + 1) * j - 1); // BBのビットを取得して書き込み、1～4の値にjを掛けて1を引く
}
(中略)

カラーパレットの書き込み中は割り込みを禁止した方が良い。
io_out8関数は8ビットのOUT命令呼び出しを表す。 ***

Rust

※僕はまだRustを弄った事が無いので間違った情報を含んでいる可能性が充分あります。
参考スライド
利点と欠点
低レイヤ界で結構人気があるコンパイル型プログラミング言語。
命令型言語と関数型言語を混ぜた感じ。
メモリ解放等がコンパイル時に静的に行われる(確認される)ので、効率が良く安全。
静的解析を行うので、コンパイルが通るまでが大変。ただし、不具合は出にくくなる。

以下は hello world プログラムの例。

fn main() {
  println!("Hello, World!!");
}

HLT命令と特権

HLT命令はリング3で動きそうな処理の命令だが、動かない。
この命令はリング0では確実に動く。(リング1、リング2で動くかどうかは知らない)
リング3で動かせないのは、アプリケーション上で実行させるとが下記の理由でOSや他のアプリケーションが困るから。
CPUが停止した何もしないスレッドは時間リソースの無駄になってしまう。
CPUを停止させる位なら、他のアプリやOSに処理を渡した方が効率的になる。
時間の同期を行うSleep関数は実際にはスレッドは呼ばれていない。
しかし、それでもHLT命令のリング3で動かせない制限は腑に落ちない。
この他のセキュリティ上の理由があるのだろうか？ ***

UEFIの注意点

ブート処理を行ったら必ずExitBootServicesを呼び出してUEFIを停止させなければならない。
- UEFIが裏で何をしているか分からない為(ハードウェアに依り実装が異なる)、OSの実行の妨げになる可能性がある。
ブートローダーとカーネルは分ける必要は無く、UEFIアプリとしてOSを開発しても良い。
ただし、この場合でもUEFIは停止しなければならない。 ***

プロテクトモード移行とパイプライン

CR0レジスタの値を書き換える等をしたら、CPUの動作モードを変更する事ができる。
CR0の値と0x00000001の論理和を取り代入すると、プロテクトモードに移行する事ができる。
- CR0の一番右側のビットが1ならプロテクトモード、0ならリアルモード。
CPUにはパイプラインと呼ばれる機能があり、命令の実行中に次の命令を先に読み込んでおき、高速に実行できる様にしている。
動作モードを変更した後はこのパイプラインを初期化しなければならない。
far JMPという命令を呼び出せば、パイプラインをフラッシュ(初期化)させる事ができ、安全に動作モードを移行させられる。

Haribote OSでは以下の様にして動作モードを移行させている。

(中略)
      LGDT		[GDTR0]			; 暫定GDTを設定
      MOV		EAX, CR0
      AND		EAX, 0x7FFFFFFF	; bit31を0にする（ページング禁止のため）
      OR		EAX, 0x00000001	; bit0を1にする（プロテクトモード移行のため）
      MOV		CR0, EAX
      JMP		pipelineflush
pipelineflush:
      MOV		AX, 1 * 8			;  読み書き可能セグメント32bit
      MOV		DS, AX
      MOV		ES, AX
      MOV		FS, AX
      MOV		GS, AX
      MOV		SS, AX
(中略)
GDT0:
      RESB		8				; ヌルセレクタ
      DW		0xFFFF, 0x0000, 0x9200, 0x00CF	; 読み書き可能セグメント32bit
      DW		0xFFFF, 0x0000, 0x9A28, 0x0047	; 実行可能セグメント32bit（bootpack用）

      DW		0
GDTR0:
      DW		8 * 3 - 1
      DD		GDT0
(中略)

注：Haribote OSのパイプラインのフラッシュ(初期化)にはfar JMPは使われていない。
実機では無くQEMU ではパイプラインのフラッシュ処理を挟まなくても正常に実行できた。
- この後に far JMP を利用してカーネル本体を呼び出しているからだろうか？
- 無駄な遅延処理を挟んでみる実験をしたけど、これでも動作した。
- もしかしたら、正常に動作している様に見えて、実は不具合が発生しているかもしれない。
Intelのマニュアル(SDMのVol.3の9.1.1)にはモードの移行後は far JMP を呼ぶ事が推奨されている。
内部動作については特に記載されていなかった。 ***

スタック領域の場所とページング

スタック領域のアドレスは0に初期化する。
- スタックは領域を上の方へ伸ばす為。
- 値が積まれるとポインタはアドレス空間の末端付近を指し示す様になる。
- スタックポインタの初期値が決まっている為、データ容量の計算は容易。
- ただし、この方法だとOSとアプリを同じページに格納する事ができない。
  - ページの切り替えは大きなコストが掛かる。
  - 脆弱性対策にはなる。
  - OS専用のコアとアプリ専用のコアを用意して、それぞれを非同期処理の様に通信する事で、コストを無くす事もできる。
    - この場合でも、アプリとライブラリは同じページに存在する事になる。
    - 更に、アプリとライブラリはスタックを共有する。
    - ライブラリに依ってはセキュリティ上問題になるかもしれないが、責任はOS開発者ではなく、アプリ・ライブラリ開発者になる。
    - セキュリティ確認機構を作れば問題ない。 ***

UEFIアプリケーションの開発について

UEFIアプリケーションの開発をする時には必ずしも EDK を使う必要は無い。最初は絶対に必要な物だと勘違いしていたが、例えば EDK II に付属している Uefi.h は UEFIの仕様に合わせてインターフェースを公開しているだけであって、仕様書を見ながら自ら定義する事もできる。 EDK II に入っているソースコードは UEFI の実装の一つである。 ***

Legacy BIOS に関する資料

Legacy BIOS に関する興味深い資料を見つけた。 https://www.glamenv-septzen.net/view/614

目次

リンク