Intelが発表したX86S Revision 1.1について(2/2) – 分析編

コメントを残す

はじめに

今回はIntelが発表した「X86S EAS Revison 1.1」の提案を分析する回です。発表された提案の具体的な内容については前回の「Intelが発表したX86S Revision 1.1について(1/2) – 詳細編」を参照いただければと思います。

なお、本メモでは「X86S EXTERNAL ARCHITECTURAL SPECIFICATION」を「X86S EAS」にリビジョン番号を付けた形で表記します。例えば前回のドキュメントについてであれば「X86S EAS 1.0」です。このように「Rev.1.0」に対して言及する場合であっても「X86-S」ではなく「X86S」と表記します。

目次

年初早々にずっこける

当初2024年1月2日（火）に公開した「Intelが発表したX86S Revision 1.1について(1/2) – 詳細編」について、編集上の問題、誤記、誤訳およびtypoが私自身で想定した以上に多数存在していました。

この「分析編」を書くために「詳細編」を見直すことになり、自分自身で驚愕しつつ修正するという作業をすることとなりました。編集をしている最中に、特に意味はないのですが、どうしても1月2日（火）中に公開したいとなぜか思ってしまっていた結果です。そして1月2日（火）の23時50分過ぎにそのまま公開してしまいました。これは完全な判断ミスです。

当初は差分で編集していたのですが、1月2日（火）の拙速な公開を経た後、原文で「Rev.1.0」と「Rev.1.1」の差分を再確認したうえで、最終的にいったん「Rev.1.1」の原文へ戻り、既訳部分について再度訳文を当てはめていく作業をしなおすことにしました。それを1月4日（木）に頭から湯気を出しつつ行っていました。全ページを見直したうえに、前回の翻訳における問題点も複数箇所発見し、今回の「詳細編」では修正を加えました。折を見て前回の「詳細編」に対しても反映（バックポート）をしたいと考えています。

その後1月4日（木）の23時55分くらいまでの更新で概ね気づいた点の修正についてを順次行いました。まだおかしなこともあるかとは思いますが、お気づきの場合にはコメント欄あるいはメールにてご指摘をいただければと思います。

Revision 1.0と1.1の主な変更点

端的に書けば「詳細編の1.2 文書の更新履歴」に記載のある内容がメインとなります。最も大きいのは、この提案の対象となる技術名が「X86-S」から「X86S」に変更されたことでしょう。また、Intelのドキュメントとしては異例なことに「ドキュメント番号（Document Number）」が更新されていないという点も指摘しておきたいと思います。

一般的なIntelのドキュメントであれば「351407-001」の「001」の部分が+1されて「351407-002」になるのが通例です。しかし、今回はドキュメント番号の更新なしに「Rev.1.0」が「Rev.1.1」へと更新されました。本メモでHTMLを記述する際には、この「ID」対して、このドキュメント番号が更新されることを前提に含めていたこともあり、いささか驚きました。

なお、変更点は大小あり、数はかなり多めです。

X86SにおけるIntel FREDとIntel SMX、Intel CETの台頭

これまでの「X86S EAS 1.0」でも「Intel FRED（Flexible Return and Event Delivery） – 以下、FREDと表記」を前提とする仕様であることが明らかでしたが、今回は「Intel TXT（Trusted Execution Technology） – 以下、TXTと表記」を前提とする「Intel SMX（Safer Mode Extensions） – 以下、SMXと表記」の記述が増え、また「Intel CET（Control-Flow Enforcement Technology） – 以下、CETと表記」についても従来以上に深く言及しています。

FREDはX86Sの土台となる技術的枠組みで、X86-64の弱点を修正してモダンなソフトウェアを動作させるのに適したプロセッサーとして、他の命令セット・アーキテクチャー（Instruction set architecture : ISA）を持つプロセッサーと同じ土俵に上がるための仕様変更をもたらすものです。

今回の「X86S EAS」はこれをさらに発展させて、X86S専用のOSやUEFIを必要とするレベルまでの改変を行い、X86-64と比較して根本的な枠組み変更を伴う仕様の提案です。その「X86S EAS 1.1」では従来以上にFREDに関連する動作の記述が増えています。事実上、FREDとX86Sは不可分の技術であるいえるレベルまで来ているように考えられます。

今回の「X86S EAS 1.1」に記述が追加されたSMXはTXTと関連する、Intelの基盤技術の一つで、信頼性の確保できたソフトウェア・モジュールを読み取って実行する仕組みです。これは当然のことながらAdvanced Micro Devices（AMD）の技術とは互換性がありません。

前回の「分析編」でも指摘しましたが、アプリケーション・レベルでは、あまり気にならないとしてもシステム・レベルではIntel 64とAMD64は部分互換性を持つ異なるアーキテクチャーです。特にシステム・レベルでは、ここで示したような互換性がない部分が各所に見られます。x86系のプロセッサーの話題を正しく理解する際には、この点を理解しておくことがとても重要です。X86Sもアプリケーション・レベルではIntel 64/AMD64とは互換性が考慮されていることからも、同様の延長線上にある考え方であることが理解できるかと思います。

CETはC/C++/アセンブリー言語などで書かれたコードに発生しやすい脆弱性からシステムを保護するための拡張仕様です。かなり強力な仕様となっており、これらの言語で書かれたソフトウェアの安全性を格段に高めることができるものとして期待されています。が、これもAMDの技術と部分的な互換性のみとなっています。

このように、今回の「X86S EAS 1.1」ではセキュリティー方面に対応する技術が明示的に多く記載されるようになってきました。

5レベル・ページ・スイッチの削除

Intelの「X86S EAS」のダウンロード用カバー・ページである「Envisioning a Simplified Intel Architecture for the Future（シンプルなIntelアーキテクチャーを思い描く）」にも記載のある「5-level paging switch（5レベル・ページ・スイッチ）」が「X86S EAS 1.1」では削除されました。そして「4-level paging switch（4レベル・ページング・スイッチ）」が「X86S」の標準仕様ということになりました。プロセッサーの起動時から「4レベル・ページング・スイッチ」で動作することが明記されています。

この変更は「5レベル・ページ・スイッチ」が本質的に「X86S」の導入目的とは無関係であると判断されたことによるのではないかと思います。

あるいはご存じのようにIntelはクライアント向けのプロセッサーにおいて、PコアとEコアの2つのプロセッサーの開発を行う必要があります。このISA仕様は同一でなければなりません。そういったことを考えるとき、「5レベル・ページ・スイッチ」の仕様を「X86S」の一部とすることに何らかの不都合があったのではないか、などと根拠のない想像を外野的としてはしてしまいますが、現実はいかがでしょうか？

リセット時の動作の明確化

プロセッサーがリセット状態から起動する際のフローがだいぶ明確化されました。レジスターがどのような初期値を持って起動してくるのかも明示されました。またIntel Confidentialと明示される資料を参照する必要のある「Firmware Interface Table（FIT）」への依存性が「X86S EAS 1.1」において削除されました。

IA-32系統のワードの復権

従来のIntel 64に関連するIntelらしいワードの選択量が「X86S EAS 1.1」では増えました。「X86S EAS」を見たIntel社内からの提案があり、それを盛り込んだ影響かもしれません。「IA-32e」と「Long Mode」の両方の表記の競演を多数見ることができます。またMSRの接頭辞としてのIA32も増加しています。

モード名としてのSupervisor/User64/User32の後退

「X86S EAS 1.0」では、16ビット・プロテクト・モードの廃止、32ビットのリング0の廃止、仮想8086モードの廃止を打ち出し、残るモードについて「Supervisor（64ビット・リング0）」「User64（64ビット・リング3）」、そして「User32（32ビット・リング3）」の各モードを用語として打ち出していました。※1

しかし、新たな「X86S EAS 1.1」では、これらの表記が後退しました。一部では「Supervisor」の表現は残るものの、「User64」と「User32」については消滅しました。個人的にはArmやRISC-Vに対して、という意味でキャッチーでわかりやすい表現であったにもかかわらず、あえて撤回した意図がよくわかりませんでした。どのよう判断があったのでしょうか？

モダン「OS」からモダン「ソフトウェア」への言い換え

「X86S EAS 1.1」では、「同1.0」で「OS」と表記していた部分の一部を「Software（ソフトウェア）」と言い換えています。「X86S」による変革はOSだけの問題ではないと考える人物が「X86S EAS 1.1」への編集に新たに関わったのではないかと感じています。

わずかな変更ではありますが、こういったことを読んで感じることができるのが、原文を読むことのモチベーションになります。

SMM（System Management Mode）への言及

先の提案「X86S EAS 1.0」において、私はSMMの処遇はどうなるんだろうかと書きましたが、今回の「X86S EAS 1.1」では明確にSMMが残ること、そしてそれがどのように動作するかが明記されることとなりました。今後もUEFIとともにSMMが活躍していくこととなりそうです。

ハードウェアを管理するという観点では確かにSMMは有用だろうとは思いますが、OSからみるとSMMは大きなブラック・ボックスで今後も存在し続けていいのかな、などと考えてしまいます。ですが、ハードウェア・メーカーとしては今後も残してほしい・あるいは必要という感じなのでしょうね。

LEGACY_REDUCED_OS_ISAへの統一

前回の提案「X86S EAS 1.0」では「LEGACY_REDUCED_OS_ISA」と「LEGACY_REDUCED_ISA」が混在していて、何に対してレガシーを削減しているのかについて、複数人いる担当メンバーの中で共通認識を得ることができていないのではないかと指摘しました。

これが今回は「LEGACY_REDUCED_OS_ISA」に統一されています。このことにより、「レガシーを削減したOS向けのISA」であるということが明確になりました。

提案を見たIntel社内のセキュリティー担当者が参加してきた？

今回の「X86S EAS 1.1」では、セキュリティー関係の追記が目立ちます。各種項目に始まり、疑似コードの中にもFRED、SMXおよびCETの表記が増えています。これは「X86S EAS 1.0」を見た社内のセキュリティー担当者がコメントを寄せた結果ではないかと想像します。それに伴って、従来よりも「X86S」は「Intel色が強いものになった」というような評価をすることもできそうです。※2

対AMDという側面

前回の「X86S EAS 1.0」時点ではAMDに対して一定の歩み寄りをし、IntelとAMDで「阿吽の呼吸」をしながら新たなX86の歴史を切り拓いていくという構想であるのかと考えていましたが、今回出てきた「X86S EAS 1.1」のIntel側技術の採用状況を見ると、それは逆であったのではないかと考えるようになりました。Intelは、Intel自身とその周りのエコシステムに関してのみを対象として再編を加えようとしているように見えます。確かに、それは「Envisioning a Simplified Intel Architecture for the Future」を素直に読めばその通りであったのかもしれません。

X86Sという枠組みのためにTXT、SMX、CET、FRED（と「Intel VT（Virtualization Technology）」全てをAMDに飲むようにと要求するのは、かなり厳しいでしょう。AMDはAMDでこれらの技術に対抗する実装を行って展開を図っている/図ろうとしているからです。特に仮想化とセキュリティー関連はそれぞれの実装が大きく異なるので、片側に寄せるのは困難ですし、これまでの対応ソフトウェアをどうするのかという問題になりそうです。

X86-64が成立したときのIntelのように、AMDが歩み寄る未来はあるのでしょうか？それとも対立を具現化するような2社による異なるISAが展開されることとなるのでしょうか？Microsoftの立ち位置は？というあたりが、今後の注目ポイントであろうと考えています。

セグメント関連のさらなる簡易化

「X86S EAS 1.1」では従来よりもセグメンテーションの簡易化が明確化されました。「X86S EAS 1.0」では例外となるものが「X86S EAS 1.1」では単に無視されるなどの変更が行われています。これによって整理されてだいぶわかりやすくなったのではないかと思います。既存のアプリケーション・プログラムを動作させる場合の影響が少ないと思われる範囲でだいぶ切り込んだ仕様なのではないかと思いながら読みました。

一方で、これまでのIntel 64対応OSをIntel VMX/VMMを含めて動作させる場合の互換性確保のシナリオについては、再検討が必要な部分が発生しています。実際、コンフォーミング・コード・セグメントは常に非コンフォーミング・コード・セグメント※3とみなされ、#GPを発生させません。しかし、「X86S EAS 1.1」における仮想化の検討部分では#GPが発生することを前提とする内容のままとなっています。

Intel 64とX86Sの間でのマイグレーションの検討

クラウド基盤として採用されたIntel 64とX86Sの間で、タスクあるいは仮想マシンをライブ・マイグレーションをする際の対応についてと考えられる記述が追加されたのはクラウド時代ゆえの要求によるものかもしれません。

確かにクラウド基盤がこれだけ一般されたIT業界の中で、「Intel 64」と「X86S」を混在させて導入した際に、クラウド基盤をどのように運営可能なのかという点について「X86 EAS 1.0」で記載がなかったことの方が不自然であったともいえそうです。

多数の表記上の修正・変更が行われた

かなり細かい表記上の変更が行われました。多くは追記ですが、これまでのビット割り当ての誤りも修正されています。例えば「X86S EAS 1.1」の「表2. 固定されたEFERビット」です。「X86S EAS 1.0」の表記では「LME」と「LMA」が反転していて、「ビット」も誤ったものが記載されていましたが、「X86S EAS 1.1」では訂正されています。また「表4. IA32_SIPI_ENTRY_STRUCT_PTR MSR（アドレス 0x3c）」についてもビットの割り付けに誤りがある点について修正されています。こうした細かい修正が疑似コードを含めて多数行われています。

なお私が従来から誤りであると考えている「表12. VMXに関連するMSRの変更点」などは修正されていません。

一方で変更点において「クリーンナップ」と表現されているように、一部の記述が興味深い形でカットされています。

まとめ

これらのIntelの「X86S EAS 1.1」を読みながら、Intelは何を成し遂げようとしているのかについて思いを巡らせてみました。それはやはり、Intelとして投資が無駄になっていると感じている製品の仕様を削減するということであるように見えます。現代においてリアル・アドレス・モードに投資することにどんなリターンを期待するかということです。あるいは16ビットあるいは32ビットのプロテクト・モードを完全にサポートすることに資源や工数を費やすことにどのような意味があるのか。そういったことを考えるとき、現代のモダンなソフトウェア（これにはUEFI、OS、およびアプリケーションが含まれる）が必要とする部分だけをサポートする「X86S」をデファクト・スタンダードに押し上げ、Microsoft WindowsとLinuxのサポートを得ることが得策であるという方向に考えているということは多くの人の意見と一致するのではないかと思います。

一方でAMDがこの仕様を互換性を維持するレベルで完全に取り込むのは「X86S EAS 1.0」よりも、Intel独自の仕様に寄った「X86S EAS 1.1」の方が難しいものになったのではないかと考えます。もちろん、法的には相互のクロス・ライスセンスを結んでいるので不可能ではありませんが、これまでの実装とは異なる仕様を採用することへのハードルは低いとは言い難いでしょう。Intel、AMD、そしてMicrosoftの間で仕様の調整が行われていくのかもしれません。

かつて「x86-64」をIntelが飲んで「Intel 64」を実装した際にはそれをしたわけではありますが、現代ではどのような展開となりますでしょうか。

変更履歴

2024年01月09日

  • 初版

2024年01月31日

  • 日本語表現がおかしい部分を修正しました。
  • 内容が重複する部分について調整を行いました。
  • 誤字・脱字を修正しました。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です