John Baldwin:
The issue found with HT is that the two logical CPUs
on a single core share the same caches and as a result there are ways
for one logical CPU to spy on the activities of the other CPU in the same core.
The proposed fixes involve ways of guaranteeing
that all of threads on a single core are all allowed to spy on each other.
For example,
one policy is that only threads with the same user ID
should be allowed to run together no the same core.
The problem is that right now FreeBSD treats logical CPUsas separate CPUs
and schedules available threads on the first CPU that becomes available.
It would be a bit of work to make the scheduler
more aware of logical CPUs and to schedule threads with respect to UIDs, etc.
HT に見付かった問題は、
二つの論理 CPU が一つのコア上で同じキャッシュを共有していることにより、
片方の CPU からもう一方の CPU の活動を覗き見ることができるというものです。
修正すれば必然的に、同じコアで動いているスレッドがすべて互いを覗ける
という保証はなくなります。例えば、ひとつの修正方針としては、同じユーザ ID を
持つスレッドだけしか同じコアで動けないようにするというものがあります。
ここで問題なのは、現時点で FreeBSD は論理 CPU を本物の CPU として扱っており、
片方の CPU にスケジュールされうるスレッドは (もう一方にも) 割り当て可能に
なってしまうということです。スケジューラを論理 CPU にもっと対応させる
(UID に合わせてスレッドをスケジュールするとか) には、ちょっと手間がかかりますね。
Robert N M Watson:
It's worth observing that this is a serious vulnerability
across a range of operating systems,
not just FreeBSD.
If you allow untrusted users on the same system as an SSH daemon,
you're at risk,which affects everyone from desktop users, to ISPs,to military end-users.
It's also a very hard problem to solve
-- we're looking at it from the perspective of improving the scheduler,
bringing in OpenSSL updates to limit timing attacks,
and obviously we're hoping that CPU vendors take this opportunity to explore how to harden
CPU architectures against this sort of attack.
Because this vulnerability isn't just about scheduling, crypto,
or hyper-threading,
a lot of hard work will have to into a long term solutions.
2. We recently read that the fix for the ... (スコア:1)
2. We recently read that the fix for the Hyper-Threading
vulnerability is considered non-trivial. Why is that?
私たちは、最近、Hyper-Threading の脆弱性のための
フィックスが重要であると考えられると読みます。
それはなぜそうですか?
John Baldwin:
The issue found with HT is that the two logical CPUs
on a single core share the same caches and as a result there are ways
for one logical CPU to spy on the activities of the other CPU in the same core.
The proposed fixes involve ways of guaranteeing
that all of threads on a single core are all allowed to spy on each other.
For example,
one policy is that only threads with the same user ID
should be allowed to run together no the same core.
The problem is that right now FreeBSD treats logical CPUsas separate CPUs
and schedules available threads on the first CPU that becomes available.
It would be a bit of work to make the scheduler
more aware of logical CPUs and to schedule threads with respect to UIDs, etc.
HTに見つけられた問題は単一のコアの2個の論理的なCPUが同じキャッシュを共有して、
1個の論理的なCPUが同じコアのもう片方のCPUの活動を探る方法が
その調査結果から存在するということです。
提案されている fix は Single core 上の Thread が、全てを監視できるというものです。
例えば,
# ここら辺りから、すでに技術背景がわかんなくなってる orz
# だれか訳して please.
# Robert N M Watson の QA も時間がないので保留中。
Re:2. We recently read that the fix for the ... (スコア:1)
読みましたが、どうしてですか。
HT に見付かった問題は、
二つの論理 CPU が一つのコア上で同じキャッシュを共有していることにより、
片方の CPU からもう一方の CPU の活動を覗き見ることができるというものです。
修正すれば必然的に、同じコアで動いているスレッドがすべて互いを覗ける
という保証はなくなります。例えば、ひとつの修正方針としては、同じユーザ ID を
持つスレッドだけしか同じコアで動けないようにするというものがあります。
ここで問題なのは、現時点で FreeBSD は論理 CPU を本物の CPU として扱っており、
片方の CPU にスケジュールされうるスレッドは (もう一方にも) 割り当て可能に
なってしまうということです。スケジューラを論理 CPU にもっと対応させる
(UID に合わせてスレッドをスケジュールするとか) には、ちょっと手間がかかりますね。
Re:2. We recently read that the fix for the ... (スコア:1)
# 自分の語学力の無さにビックリ。
とりあえず原文のせて、手があいている人に訳してもらうか。
僕も、今日、家に戻ったら原文 2 つぐらい訳せるかも知れないし。
Re:2. We recently read that the fix for the ... (スコア:1)
「提案されている修正は、同じコアで動いているスレッドがすべて互い(の状況)を覗いてもよいことを保証することを含んでいます」、じゃないでしょうか?
Re:2. We recently read that the fix for the ... (スコア:2)
そうですね。逆の意味になっていますね。
ご指摘ありがとうございます。
「複数ある修正案には、同じコアのスレッド同士が互いを覗き見てもかまわないようにする方法が関係しています。」
を私の案として提出いたします。
Re:2. We recently read that the fix for the ... (スコア:1)
It's worth observing that this is a serious vulnerability
across a range of operating systems,
not just FreeBSD.
If you allow untrusted users on the same system as an SSH daemon,
you're at risk,which affects everyone from desktop users, to ISPs,to military end-users.
It's also a very hard problem to solve
-- we're looking at it from the perspective of improving the scheduler,
bringing in OpenSSL updates to limit timing attacks,
and obviously we're hoping that CPU vendors take this opportunity to explore how to harden
CPU architectures against this sort of attack.
Because this vulnerability isn't just about scheduling, crypto,
or hyper-threading,
a lot of hard work will have to into a long term solutions.
Re:2. We recently read that the fix for the ... (スコア:1)
これが OS をまたいだ脆弱性であり、FreeBSD だけの問題ではないという点は
注目に値します。信用できないユーザが同じシステムに入ることを SSH が許可
しているなら誰でもこの危険にさらされているのであり、デスクトップユーザから、
ISP や軍関係のエンドユーザにまで影響する問題なのです。そしてこれは非常に
難しい問題です。我々はスケジューラを改善するという視点から見たり、OpenSSL
をアップデートしてタイミング攻撃を制限したりしていますし、さらには CPU
ベンダがこの機会をとらえて、こうした問題に対してより堅牢なアーキテクチャを
探るようになってほしいとも願っています。この脆弱性は単にスケジューリングや
暗号やハイパースレッディングの問題というわけではないため、長期的な解決には
多大の労力が必要となるでしょう。