最近、Azul Systems の CTO 兼共同創設者である Gil Tene が、非常に重要だがほとんど知られていない Linux カーネル パッチを GoogleGroups で報告しました。Intel Haswell アーキテクチャを使用する Linux システムのユーザーと管理者は、この問題に特に注意を払う必要があります。特に Red Hat ディストリビューション (CentOS 6.6 および Scientific Linux 6.6 を含む) をベースとするユーザーは、このパッチを直ちに更新する必要があります。 Linux が仮想マシンで実行されている場合でも、仮想マシンが一般的なクラウド プラットフォーム (Azure、Amazon など) 上にある場合は、Haswell マシン上でも実行されている可能性があり、パッチを適用することは有益です。
Tene はこの欠陥について次のように説明しています:
このカーネルの脆弱性の影響は非常に単純です。一見不可能と思われる状況では、ユーザー プロセスがデッドロックしてハングします。待機中の futex 呼び出しは (正しく起動された場合でも)、実行が永久にブロックされる可能性があります。 Java の Thread.park() が永久にブロックされる可能性があるのと同様です。運が良ければ dmesg ログにソフト ロックアップ メッセージが見つかるかもしれませんが、運が悪ければ (私たちのように)、コードの問題のトラブルシューティングに数か月の人件費を費やす必要があり、見つからない可能性もあります。何でも。
Tene は、欠陥のあるコードがどのように実行されたかについて説明を続けました (最終的には、デフォルトのケースを見逃したスイッチ ブロックに行き着きました)。今の大きな疑問は、問題のあるコードは 2014 年 1 月に修正されましたが、2014 年頃には修正されたということです。 10 月、この欠陥は Red Hat 6.6 ファミリ システムに戻されました。SLES、Ubuntu、Debian などの他のシステムにも影響が及ぶ可能性があります。
これらのシステムの修復ステータスは現在一貫性がないため、RedHat ユーザーは無視される可能性があります。 Tene 氏は、もう 1 つの重要な点は、カーネルに何を組み込むかについての選択肢が異なること、つまり、RHEL 7.1 の場合には一貫性がなくなることであると指摘しました。 、「実際には、アップストリーム 3.10 カーネルにはこのバグはありませんが、RHEL7 カーネルは純粋なアップストリーム バージョンではありません。残念ながら、RHEL 7.1 (RHEL 6.6 と同様) には、(RHEL 7 バージョンに基づく) ポートにこのバグが含まれていました...他のディストリビューションでも同様のことが行われた可能性があると思います。
RHEL ベースのディストリビューションについては、Tene がクイック リファレンス リストを提供しています。
l RHEL 5 (CentOS5 および Scientific Linux 5 を含む): すべてのバージョン (バージョン 5.11 を含む) には問題はありません。
l RHEL 6 (CentOS6 および Scientific Linux 5 を含む)。 Scientific Linux 6): バージョン 6.0 から 6.5 までは問題ありませんが、バージョン 6.6 には問題があり、RHEL 7 (CentOS7 および Scientific Linux 7 を含む) には問題がありません。 2015 年 5 月 13 日時点では 7.x の修正ではありません
影響を受けるシステムの数については Hacker News でいくつかの議論がありますが、システムに修正が必要かどうかを確認するためのコンテキストを提供します LAMP Brothers のオリジナル Linux を入手してください運用保守エンジニアのビデオ/詳細な Linux チュートリアル (無料) 詳細については、公式カスタマー サービスにお問い合わせください: http://www.lampbrother.net/linux/
|