ソフトウェアの地獄やその他の最新のオペレーティングシステムのトラブルについて考えてみると、バイトコードとそれがどのような予期せぬ場所で使用できるかについての興味深い記事に出会いました。 この記事は上記の内容を反映しているように思えるので、翻訳してここに掲載することにしました。 これはハブでの最初の翻訳なので、厳密に判断しないでください。 翻訳、エラーなどについてコメントがある場合 PMに書いてください。
世界で最も使用されているバイトコードはどれですか？ Java（JVMバイトコード）？ .NET（CLI）？ フラッシュ（AVM1 \ AVM2）？ いや 毎日使用するいくつかのバイトコードがあり、コンピューター、タブレット、または携帯電話の電源を入れるだけです。 アプリケーションを実行したり、インターネット上のページにアクセスしたりする必要さえありません。
ACPI
おそらく最も一般的な使用法はACPIバイトコードです。 ACPI（Advanced Configuration and Power Interface） 仕様は、1,000ページ近くの巨大なドキュメントです。 もちろん、オペレーティングシステムは仕様に従って実装する必要があることが理解されています。 完全かつ完全に。 バイトコード部分は、第20章「ACPI Machine Language」にあります。これは、Add、Substract、Multiply、Divide、比較操作、ToHexStringやMid（基本的にサブストリング）などのすばらしいコマンドの典型的なコマンドセットを持つ仮想マシンの登録について説明しています。 さらに読むと、完全なオブジェクトモデル、システムプロパティの仕様、およびシステムプロパティのいずれかが変更されたときにトリガーする非同期通知メカニズムに遭遇します。
もちろん、ほとんどのデバイスはACPI仕様に完全に従う必要があるため、仕様はオペレーティングシステムのカーネルレベル（ Linuxでの実装など）で完全に実装されます。 このコードはすべて、オペレーティングシステムのロードの初期段階で実行されます。 実装と実行の複雑さという点では、これはすべてJavaScriptとその環境の完全な実装に匹敵します。 ACPI仕様は非常に複雑であるため、Intelは仕様のプラットフォームに依存しない実装-ACPICAを作成しました。この実装は、LinuxおよびBSDカーネル（Mac OSを含む）、およびReactOSやHaikuOSなどのシステムで使用されます。 Windowsがこの実装を使用しているかどうかはわかりませんが、 Microsoftの名前は仕様に含まれており、その実装はACPICAよりもずっと前に作成されたと思います。
フォント
続けて、グラフィカルなブートローダーが必要ですか？ フォントをOpenType形式で簡単に表示するには（CFFグリフを含むOpenTypeフォントのみ、OpenTypeフォント形式の複雑さは会話の別のトピックです）、 Type 2 Glyph形式でデータを解析する必要があります。これには、グリフを作成するための専用バイトコードの実行も含まれます。 このバイトコードはさらに興味深いものです。実際のスタックインタープリタであり、実行時にランダムに表示されるグリフを作成できる「ランダム」コマンドもあります。 少なくともこの機能の便利なアプリケーション（FreeTypeフォントでも実装されていた）が想像できないので、実際にどこかで使用されているとしか考えられません。 このバイトコードのインタープリターは、 スタックオーバーフローの脆弱性で知られているため、 iPhoneを特別に生成されたPDFファイルのジェイルブレイクにすることができます。
グリフ形成言語は、 PostScript言語の簡易バージョンです 。 PostScriptは、Forth言語のアイデアに基づいて、フルチューニングのレジスタスタック仮想マシンを実装しています。 このシステムの欠点（永続的なループ、1ページだけを表示する必要がある場合でも、ドキュメント全体の解釈、およびドキュメントの状態の内部表現の複雑さのためにすべて）は、PostScriptに基づいているが、ドキュメントのグローバルな状態を含まないPDF形式の出現の主な理由となっています操作の任意の順序。 たとえば、このモデルでは、何も追加せずにドキュメントに追加された画像を確認するのは非常に簡単です。
そしてもちろん、 フォントは複雑で、OpenType仕様も複雑です。また、TrueTypeフォント仕様全体が含まれています。これには、 どの画面解像度でも同じように見えるフォントを表示するためのバイトコードモデルが記述されています 。 これらの仕様のジャングルには深く入りません。 FreeTypeの実装は次のとおりです。 ここではあまりおもしろいことはしていませんが、かつてここで脆弱性が見つかったようです。
この記事を画面で見るには、これらの小さなマイクロプログラムを何千も実行して、画面上の各フォントの正しいグリフ形状を形成します。
パケットフィルタリング
さらに、tcpdumpまたはlibpcapを使用して（またはWiresharkなどのそれらに基づくユーティリティを使用して）ネットワークパケットをインターセプトする場合、レジスタバイトコードに基づいてBerkeleyパケットフィルターが使用されます。 ネットワークをデバッグする人々にとってパフォーマンスは非常に重要であったため、シンプルなLinuxカーネルレベルのJITコンパイラも実装されました。
歴史に興味がある人にとっては、BPFの以前の実装はLinuxに対するSCO訴訟に関係するコードの一部でしたが、一般にBPFはBSD4.3のコードの一部であり、Linuxカーネルに単純にコピーされていました。 BPFは、後にLinux Socket Filterと呼ばれる新しい実装に置き換えられました。
さて、なぜこれすべてですか？
ユニバーサルで柔軟なソリューションとしてのバイトコードの人気は非常に魅力的ですが、同時に、バイトコードは複雑さを排除せず、一般的なデバイスのセキュリティ（iPhoneの完全な脱獄は単にスタックオーバーフローによるものです）や仕様を実装するためのめちゃくちゃ複雑な要件など、多くの潜在的な問題を解決しません非常に複雑であるため、ACPIメカニズムの実装は現在1つだけであり、今日のオペレーティングシステムのほとんどで使用されています。
調べた4つの例も興味深いものを示しています-バイトコードを使用できる非常に異なる状況です。 ACPIの場合、これは最初に宣言された仕様のい実装と思われるものの興味深い外観であり、現在は完全に混乱しています。 フォント言語Type 2 GlyphおよびTrueType Hintingは、PostScriptのレガシーを示す基本的なスタックインタープリターです。 また、BPFはレジスタインタプリタであり、かなり奇妙なレジスタ言語を使用して、非常に単純な操作のみを実行できます。
また、バイトコードインタープリターの実装はそれほど簡単な作業ではないため、上記の実装にはすべてセキュリティ上の問題があったことにも注意してください。 最後に、ハッカーへの質問-バイトコードに関する他の同様の難解な仕様を知っていますか？ そして、問題は仕様の作成者にあります-あなたは本当にそのような柔軟性が必要ですか？
翻訳者から
元の記事に対するコメントからの興味深いリンク：
UEFIバイトコードセクション20を参照
Sqliteバイトコード
RARアーカイババイトコード
バイトコード
All Articles