回答:
の「バグ」フィールドの意図は、それを導入/proc/cpuinfo
したコミットメッセージで説明されています。
x86/cpufeature
:バグフラグを追加/proc/cpuinfo
機能フラグと同様の方法で、実行中のCPUにバグの回避策を検出または適用したことを示すフラグをダンプします。
利点は、CPU機能のように時間の経過とともに蓄積されないことです。
以前は、カーネルが検出したハードウェアバグは個別の機能としてリストされていました(たとえば、32ビットx86システムに独自のf00f_bug
エントリがある悪名高いF00Fバグ/proc/cpuinfo
)。「バグ」エントリは、x86 CPUフラグと同じスタイルで、これらを単一の機能で保持するために導入されました。
メッセージでわかるように、実際のエントリの意味については、カーネルがハードウェアのバグを検出したことだけが保証されています。他の場所を見る必要があります(ブートメッセージ、または特定の/proc
エントリまたは/sys
ファイルなどのエントリ/sys/devices/system/cpu/vulnerabilities/
問題が処理されているかどうかを判断するには、)を調べる必要があります。
「バグ」エントリの有用性は2つの方法で制限されています。1つ目は、真のネガは未知のものと区別できないことです。フィールドに「cpu_meltdown」が指定されていない場合、カーネルがMeltdownを認識していないことを意味するかどうかを(フィールドから)知ることができません。 CPUがメルトダウンの影響を受けないこと。2つ目は、検出が単純すぎる可能性があることです。警告の側でエラーが発生するため、CPUが脆弱でない場合でも脆弱であると報告される場合があります。「検出」はテーブル駆動型であるため、その精度は実行しているカーネルのバージョンに依存します。
メルトダウンとスペクターのバグの場合、x86では、値を供給する検出プロセス/proc/cpuinfo
は次のように機能します。
Meltdown / Spectreの脆弱性はCPUチップセットの設計/アーキテクチャにあり、新しい将来のハードウェアを購入する手間がかからず、パッチは長期にわたるセキュリティの素晴らしい幻想です。欠陥を悪用する新しい方法は、現在のパッチをバイパスできる可能性があります。
つまり、現在のソフトウェアパッチ/マイクロコードは、Spectre / Meltdownファミリーのエクスプロイトの既知の方法に対する問題を軽減しますが、そもそもそれらを可能にする根本的なCPU設計の問題を解決しません。影響を受けた(数世代の)CPUは、長期的には脆弱性を持つのを止めていません(おそらくほとんどそうはならないでしょう)。
ただし、@ Gillesが正しく述べているように、その警告は現在の既知の悪用Spectre / Meltdownメソッドが機能することを意味しません。パッチがインストールされている場合は機能しません。
質問で言及されたケースでは、カーネルはSpectre / Meltdownの影響を受けることが知られているCPUモデル(x86についてのみ話している場合は現在のところすべてのx86 CPU)のみをチェックしているためcpu-insecure
、バグセクションにまだリストされています/ line in /proc/cpuinfo
。
を確認してください
/proc/cpuinfo
。カーネルにKPTIパッチがある場合、cpu_insecureが含まれますKPTIパッチには次のコードが含まれていることがわかりました。
/* Assume for now that ALL x86 CPUs are insecure */ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
そして、カーネルの更新後、次のものが得られます。
bugs : cpu_insecure
PS。Spectre / Meltdownの「バグ」を悪用する新しい方法のアップデートがすでにありました。おそらく最後ではないでしょう。
/proc/cpuinfo
、ソフトウェアパッチによって完全に軽減された場合でもリストされます。それらの存在は、システムがその特定のバグに対して脆弱であることを意味するものではありません。
bugs
ラインショーに当てはまることを書きました、そして、これはちょうど間違っています。ほとんどのCPU設計のバグには、わずかなパフォーマンスしか必要としない完全なソフトウェア回避策があります。カーネルが回避策を適用する場合、バグは無害です。