stivale.md 3.4 KB
Easyboot の Stivale サポート
そんなことは絶対に起こりません。このブート プロトコルには、非常に重大な不適切な設計上の選択がいくつかあり、セキュリティ上の大きなリスクとなります。
まず、stivale カーネルには ELF ヘッダーがありますが、ヘッダーが有効でないことはわかっているはずです。ヘッダーには、有効な SysV ABI カーネルではないことを示すものはまったくありません。 マルチブートでは、プロトコルを検出できるように、ファイルの先頭にマジック バイトがいくつかある必要がありますが、stivale / stivale2 にはそのようなものはありません。 (アンカーは役に立ちません。これは、ファイル内の どこにでも 発生する可能性があるためです。そのため、stivale と互換性がないことを確認するには、実際には ファイル全体を検索 する必要があります。)
2 番目に、セクションを使用します。ELF 仕様 (ページ 46 を参照) によれば、セクションはオプションであり、 ローダーは気にする必要はありません。ローダーは実行ビューを使用し、リンク ビューは使用しません。この 1 つのプロトコルのためだけにセクション解析を実装することは、 システム リソースがすでに不足していることが多いローダーにとって、非常に大きなオーバーヘッドになります。
3 番目に、セクション ヘッダーはファイルの末尾にあります。つまり、stivale を検出するには、ファイルの先頭をロードし、ELF ヘッダーを解析し、 次にファイルの末尾をロードしてセクション ヘッダーを解析し、次にファイルの中間からロードして実際のタグ リストを取得する必要があります。 これは考えられる最悪の解決策です。また、ローダーがこれを行う必要があることを示すものはまったくないため、カーネルが stivale を使用していないことを確認するために、 すべてのカーネルに対してこれを実行する必要があります。これにより、他のすべての ブート プロトコルの検出も遅くなり、これは許容できません。
タグ リストはアプリケーション プロセッサによってアクティブにポーリングされ、カーネルはいつでもブート ローダー コードを呼び出す可能性があります。つまり、 ブート ローダーのメモリを再利用することはできず、再利用しないとクラッシュが保証されます。これは、Easyboot の哲学に反します。
最悪なのは、このプロトコルではブートローダーが任意の stivale 互換カーネルにコードを挿入し、それが可能な限り最高の権限レベルで実行されることを期待していることです。 ええ、何が問題になるでしょうか?
私は質の悪いコードを手放すことを拒否しているので、Easyboot ではスティヴァル サポートはありません。そして、私のアドバイスに従うなら、趣味の OS 開発者は、 自分自身のためにも決してそれを使用するべきではありません。