トップページ⇒unix
110コメント31KB

IntelのHTTに深刻な脆弱性

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2005/05/14(土) 13:32:27
Intelのハイパースレッディングに深刻な脆弱性
http://www.itmedia.co.jp/enterprise/articles/0505/14/news009.html
0002名無しさん＠お腹いっぱい。2005/05/14(土) 13:41:19
Intelﾀﾞﾒﾎﾟ…
0003名無しさん＠お腹いっぱい。2005/05/14(土) 13:49:16
で、セキュリティアップデートはいつでるんだ？
0004名無しさん＠お腹いっぱい。2005/05/14(土) 13:54:15
コリンきゅんがIntelに訴えられて京都府警にタイーホされる展開キボン
0005名無しさん＠お腹いっぱい。2005/05/14(土) 14:02:24
つか論文読んだけどすごーく微妙で「強く勧告する」ほどの問題じゃねーな。
local information leakだし、低〜中程度の脅威。
「深刻」ってのはハードウェアの設計を根本的に見直さないと対策が難しいからか。
0006名無しさん＠お腹いっぱい。2005/05/14(土) 14:45:34
HTT の脆弱性というか SMT ってそういうものだろ。
そのうち各 OS ベンダーからパッチが出て終わりなんじゃないの?
0007名無しさん＠お腹いっぱい。2005/05/14(土) 14:49:11
って、まあ *BSD はパッチでてるけどな
0008名無しさん＠お腹いっぱい。2005/05/14(土) 15:50:53
そうね。でもまあCPUの方で対応するのがベストな事案ではあるね。
0009名無しさん＠お腹いっぱい。2005/05/14(土) 19:22:48
OSの実装じゃなくてHTTそのものに脆弱性なの？
0010名無しさん＠お腹いっぱい。2005/05/14(土) 19:42:14
んだ
0011名無しさん＠お腹いっぱい。2005/05/14(土) 20:38:47
セキュリティ上の脅威ってほどでもない問題だけどIntelにとっては脅威だな。
AMDサーバ買おうとしてる奴にとって上司を説得するネタにはなる。
0012名無しさん＠お腹いっぱい。2005/05/14(土) 20:47:45
この程度ならカーネル側でなんとでも対応できるだろ。
0013名無しさん＠お腹いっぱい。NGNG
この程度なら運用でなんとでも対応できるだろ。
0014名無しさん＠お腹いっぱい。2005/05/14(土) 21:02:30
関連スレッド
http://groups.google.co.jp/group/sci.crypt/browse_thread/thread/fdfdcff637cc21f4/b60b10c13f809d9c?hl=ja
http://groups.google.co.jp/group/fa.linux.kernel/browse_thread/thread/6de219af720cddfc/04e19756a1267c66?hl=ja
0015名無しさん＠お腹いっぱい。2005/05/14(土) 21:03:08
さりげにSCOとFreeBSDがタッグを組んでるな
0016名無しさん＠お腹いっぱい。2005/05/14(土) 22:27:10
>>9
Colinはそう言ってるけど、Intelは仕様だって言うんじゃないかと思う。
投機スレッドをHTTで動かしてメモリレイテンシを削減する技術の提案とかしてるし。

やっぱスケジューラががんばって洩れても平気なスレッド同士しか同じコアに
割り振らないようにするしかないんじゃないかな。
0017名無しさん＠お腹いっぱい。2005/05/15(日) 00:06:48
どっちにしろHTTなんて消えてゆくテクノロジなんだから使わないのが一番だろ
0018名無しさん＠お腹いっぱい。2005/05/15(日) 02:01:53
セロ林でも大して変わらんな
0019名無しさん＠お腹いっぱい。2005/05/15(日) 03:10:18
これからのサーバはPentium Mを使った省電力化がトレンド。
0020名無しさん＠お腹いっぱい。2005/05/15(日) 19:05:55
別にHTTに特有の問題じゃなくて、キャッシュ共有型マルチコア
CPUでも全く同じ問題があるでしょ。個人的感想は>>5と同じ。

>>7
OpenBSDは対策とるつもりがないみたいだから、もしもこの件を
重視するならFreeBSDの方が安全だよ。
どうでもいいけど、HTTに直接対応してなくても影響を受ける
のに、そのことを理解してないような文面なのもなんだかなと
思った。
0021名無しさん＠お腹いっぱい。2005/05/17(火) 01:14:14
対策も何もFreeBSDはHTTをoffにしてるだけみたいだが。
0022名無しさん＠お腹いっぱい。2005/05/17(火) 10:19:35
つーか、対策としてはHTTをOFFにするしかないかと…
0023名無しさん＠お腹いっぱい。2005/05/17(火) 11:16:24
そういうことだ。
どのOSが安全とかじゃなくてさっさとHTToffにして再起動しろと。
0024名無しさん＠お腹いっぱい。2005/05/17(火) 11:20:22
HTTを無効にしてるのは暫定的な対策だよ。DESが
ttp://lists.freebsd.org/pipermail/freebsd-security/2005-May/002917.html
で書いてるように、Colinの提案どおり同一プロセス内のスレッドのみを割り
振るようにするのがパフォーマンス的にも好ましい対策。
FreeBSDではまずULEスケジューラをちゃんとしないといけないけど。。。
0025名無しさん＠お腹いっぱい。2005/05/17(火) 11:44:18
マルチスレッドで組んでるプログラムのピーク値を引き上げる効果はあるだろうが
全体としたらやはりパフォーマンスを落す結果になりそうだが。
0026名無しさん＠お腹いっぱい。2005/05/17(火) 18:53:27
>>24
書いてもいいよね？　(´A｀)ﾏﾝﾄﾞｸｾ
0027名無しさん＠お腹いっぱい。2005/05/18(水) 10:20:36
http://pcweb.mycom.co.jp/articles/2005/05/17/ht/
Hyper-Threadingの脆弱性 - そのメカニズムとは?
0028名無しさん＠お腹いっぱい。2005/05/18(水) 12:20:59
深刻って言うほど深刻でもないような。見知らぬあなたと見知らぬあなたが
マルチユーザで使ってるような場合には問題になることもあるかもしれないけど。
0029名無しさん＠お腹いっぱい。2005/05/18(水) 13:03:08
多くのホスティングWebサーバがHTTを使ってる予感
0030名無しさん＠お腹いっぱい。2005/05/18(水) 13:19:33
使ってないだろw
0031名無しさん＠お腹いっぱい。2005/05/18(水) 18:30:22
ｗｗｗｗｗｗっうぇｗｗｗｗｗｗｗ絵ウェwwwwwwwっウェwwwwwっウェwwwwっウェ
wwwwwwwwwwwwwwwwwwwwっウェwwwwwwwwwwwwwwwっウェwwwwwｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0032名無しさん＠お腹いっぱい。2005/05/18(水) 20:43:54
ホスティングしてる客には秘密でHT使ってるに、10000ルピー
0033名無しさん＠お腹いっぱい。2005/05/18(水) 23:19:38
>>27
バカバカしい。その時にhyper threadingで同時に実行されている
相手が何をしているか知る手段が提示されていない。
0034名無しさん＠お腹いっぱい。2005/05/18(水) 23:39:03
$ ps
0035名無しさん＠お腹いっぱい。2005/05/18(水) 23:45:41
>>33
最初の段落に論文へのリンクがはってあるよ
0036名無しさん＠お腹いっぱい。2005/05/19(木) 00:04:17
俺これの脅威がさっぱりわからないんだけど、大人数のユーザが同時にいろんなプロセスを実行してたら
憶測しようにもなにがなんやら分からんのでは？
0037きじゃくせいについて2005/05/19(木) 00:59:38
↓ここでTheo君の登場
0038名無しさん＠お腹いっぱい。2005/05/19(木) 01:20:54
↑
きじゃくせい？
0039名無しさん＠お腹いっぱい。2005/05/19(木) 01:40:06
気弱性について
0040名無しさん＠お腹いっぱい。2005/05/19(木) 02:59:15
Unixのたいていのセキュリティ技術は他のプロセスのメモリ空間には
アクセスできないはずだというのをまず大前提としているんだけど、
HTT の問題ではこの前提が成り立たなくなっちゃう。

なので、いろんなセキュリティ機構が役に立たなくなる(HTT の問題を
悪用すると抜け道が作れてしまう)のでやばい、ってところだね。
0041名無しさん＠お腹いっぱい。2005/05/19(木) 06:13:38
>>40
……まあ、論文を読んでみなさい。
0042名無しさん＠お腹いっぱい。2005/05/19(木) 07:50:12
そんな含みを持ったもったいぶった書き方するくらいなら、
説明してやればいいのに。
0043名無しさん＠お腹いっぱい。2005/05/19(木) 07:56:03
>>27
これ読めばいいじゃん。
0044名無しさん＠お腹いっぱい。2005/05/19(木) 13:13:50
>>1
AMD信者のデマだよもん
0045名無しさん＠お腹いっぱい。2005/05/19(木) 13:36:45
>>40
HTであってもアクセスはできない。
応答時間で当たり外れを推測するもの。
推測が当たるも外れるも運次第だ。

0046名無しさん＠お腹いっぱい。2005/05/19(木) 13:40:43
DNSサーバーへの問い合わせでキャッシュに残っていたから
「誰かがアクセスしたはずである」というのを脆弱性と呼ぶのか？
HTを脆弱というならDNSのキャッシュも脆弱だと言ってくれ。
串サーバーのキャッシュも脆弱だと言ってくれ。
そもろもDNSもHTも串も誰がキャッシュに残したのか？はそもそも不明。
0047名無しさん＠お腹いっぱい。2005/05/19(木) 13:59:01
>>46
( ﾟ,_ゝﾟ)ﾊﾞｶｼﾞｬﾈｰﾉ
0048名無しさん＠お腹いっぱい。2005/05/19(木) 14:22:58
>>46
じゃなくて、暗号を復号する時の具体的なアルゴリズム、
場合によってはバイナリプログラムが特定されていて、
別スレッドが今どんなオペレーションを実行しているかが推測できれば
アルゴリズム上の実行パスを推測することができて、
それを暗号を推測するために使うことができる、ということでしょ。

例えば、ここで3回連続多倍長の乗算をしているから、この条件分岐は
true側だったはずなんで、じゃあこのビットは1のはずだろう、とか。
0049名無しさん＠お腹いっぱい。2005/05/19(木) 19:46:41
>>46
そこまでまったく意味が分かってないのによくレスする気になったもんだｗ
0050名無しさん＠お腹いっぱい。2005/05/19(木) 19:55:09
キャッシュという言葉だけ理解できたんだろう
0051名無しさん＠お腹いっぱい。2005/05/19(木) 20:26:19
キャッシュカードの脆弱性について
0052名無しさん＠お腹いっぱい。2005/05/19(木) 20:33:59
>>51
財布にいれずにジーパンのポケットに突っ込んでおくと
割れて使い物にならなくなる.
0053名無しさん＠お腹いっぱい。2005/05/19(木) 20:36:58
キャッシュカードはタクティカルベストのハンドグレネードポーチに入れましょう。
0054名無しさん＠お腹いっぱい。2005/05/19(木) 21:32:19
ジーパンにセキュリティホールを発見した
0055名無しさん＠お腹いっぱい。2005/05/19(木) 21:34:36
サイバーノーパンぶらり戦法で万全
0056名無しさん＠お腹いっぱい。2005/05/19(木) 22:00:55
>>51
それ以前に、つづりが違うだろ。

cash card
http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%82%AB%E3%83%BC%E3%83%89

cache
http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5_%28%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%29
0057名無しさん＠お腹いっぱい。2005/05/19(木) 22:02:24
>>54
それ、ただの閉め忘れだろ。
0058名無しさん＠お腹いっぱい。2005/05/19(木) 22:14:51
queueとcacheはなかなか綴りを覚えられなかった
0059名無しさん＠お腹いっぱい。2005/05/19(木) 22:15:35
ジーパンのジッパーには潜在的な危険性があるらしい
0060名無しさん＠お腹いっぱい。2005/05/19(木) 22:18:10
ジッパー内に秘密鍵ﾊｹｰﾝしました
0061名無しさん＠お腹いっぱい。2005/05/19(木) 22:44:14
>>59
ジーパンにかぎんねぇだろ?
ズボンについてるジッパーの危険性に大差はないと思うぞ,
急いでるときは特に...
0062名無しさん＠お腹いっぱい。2005/05/19(木) 22:51:43
雪国だと冬、家に帰ってきてトイレに駆け込んだとき必死だぜ
0063名無しさん＠お腹いっぱい。2005/05/19(木) 23:06:21
結局のところ、シングルCPUでシングルコアでHTを使うと危険ということかな？
SMPだとどのプロセッサーでスレッドが走るかを予測することも指定することもできない。
マルチコアだとどのコアでスレッドが走るかを予測することも指定するこもできない。
キケンな環境でHT使っている香具師はとっととBIOSの設定を変えるべし。
SMP用のカーネルだけを入れている人は大変かも？
0064名無しさん＠お腹いっぱい。2005/05/19(木) 23:12:18
ただちに HTT を無効にすべきというほど危険じゃない
0065名無しさん＠お腹いっぱい。2005/05/19(木) 23:48:17
>>63
> マルチコアだとどのコアでスレッドが走るかを予測することも指定するこもできない。
2nd cache 共有のタイプだと, cache の構成によっては似たような事は
可能だと思われる.
0066名無しさん＠お腹いっぱい。2005/05/19(木) 23:54:41
悪用するのは大変難しいといいつつも実証コードが出ちゃったのが問題だね。

ここの説明が判りやすいかも。
ttp://w3.quake3.jp/sushi-k/index.php?itemid=321
0067名無しさん＠お腹いっぱい。2005/05/19(木) 23:57:40
マルチコアじゃなくても、Opteronみたいに
|メモリ| -- |[L2$]-[コア]| --- |[コア]-[L2$]| -- [メモリ]
みたいな構成でもレイテンシに差が出るよ。
SMTだとL1$を共有してるから精度が高いってだけ。
0068名無しさん＠お腹いっぱい。2005/05/20(金) 00:08:07
マルチタスクでマルチユーザーの環境では安全では？
0069名無しさん＠お腹いっぱい。2005/05/20(金) 00:42:12
>>68
典型的な例として、複数ユーザを詰め込んだレンタルサーバでやられるとどうなると思う？
0070名無しさん＠お腹いっぱい。2005/05/20(金) 00:59:46
この脆弱性を利用して侵入してくる奴がいたらうちで雇う
0071名無しさん＠お腹いっぱい。2005/05/20(金) 01:00:04
>>69
どうにもならないでしょ。
今回の発表はOpenSSLの特定のバージョンでRSA署名をし続けた場合の実証
でしかなく、"real-world"での漏洩はまず無理だし。
0072名無しさん＠お腹いっぱい。2005/05/20(金) 01:34:02
>>69
より安全性が高まるだけでは？
0073名無しさん＠お腹いっぱい。2005/05/20(金) 03:45:50
ようするに、この
"ArchitecutualState"というのが
"ProcessorCore"を共有しているのがまずい??

ttp://www.fbmnd.fh-frankfurt.de/~doeben/II-INF3/II-INF3-TH/VL12/intel-hyperthreading-700.jpg


>>66
>プロセスのキャッシュのアクセス速度の変化パターンから鍵を類推

OpenSSLがセキュリティ・アップデートで
鎮火?
0074名無しさん＠お腹いっぱい。2005/05/20(金) 05:02:57
>>73
>>41
0075名無しさん＠お腹いっぱい。2005/05/20(金) 07:02:52
>>71
やっぱりライバル会社の妨害工作か・・・・
0076名無しさん＠お腹いっぱい。2005/05/20(金) 09:24:09
リモートからの攻撃ではないから安心とか、実証コードは特定のSSLの
バージョンだけだから安心とか。。。。

Theoと喧嘩になるような人ばかりですね。

実証コードを元にSSLキーロガーなるものががアンダーグラウンドで流通し
亜流が増え続けるのは時間の問題。
インターネットカフェに仕込むキーボードロガーのようにお宝に当たれば桶という使い方になる。
SSL以外にも順次適用拡大していくんだろうね。
実はレンタルサーバにはあちこち入りはじめているんじゃねーの？
と思ったら深刻な脆弱性という評価になるわけだが。
0077名無しさん＠お腹いっぱい。2005/05/20(金) 10:27:53
４ビットや８ビットのマイコンのプログラミングの経験があれば想像できる。
条件が真か偽かでステップ数が異なると処理時間が違ってくるんです。
だからNOPを入れて実ステップ数（時間）を合わせるんです。
特定の演算ユニットがBUSYでもBUSYでなくても処理時間が同じになれば
いいんですよ。
つまり。。。

0078名無しさん＠お腹いっぱい。2005/05/20(金) 14:05:21
ここまで読んだ。

唯一残念なのは、このスレで参考になった物が一つもなかった事だ。
0079名無しさん＠お腹いっぱい。2005/05/20(金) 14:13:25
>>78は全く参考にならんな。
0080名無しさん＠お腹いっぱい。2005/05/20(金) 15:40:30
>>80 も全くｓｙんづお
Stack overflow
0081名無しさん＠お腹いっぱい。2005/05/20(金) 23:43:20
Z80のリフレッシュレジスタを掴んでたまにスタックオーバフロー起こさせて連荘させるパチンコのあれか？
よしOpenSSLの次バージョンはそれでいこうじゃないか。（Z80限定サポート）
0082名無しさん＠お腹いっぱい。2005/05/21(土) 13:46:27
INVD (0F08)
flush internal caches; initiate flushing of external caches.
...
The INVD instruction is a privilieged
...

というのをカーネルモードでやると
どうでsか?　却下?
0083名無しさん＠お腹いっぱい。2005/05/21(土) 13:54:21
>>69
同時に動いているプロセス/スレッドがSSLだけという条件が必要だろ。
つまり、全然現実的じゃない。例えば一緒にapacheでも動かして
トラフィックかかってればレイテンシのパターンは読めなくなる。
0084名無しさん＠お腹いっぱい。2005/05/21(土) 14:50:31
>>83
そうとも言えないんじゃないかな。
強い局所性でサイドチャネルにエラー(誤情報)が載るか、
それとも対象プロセスの局所性をマスクするほど大量の負荷が同時に
かかっていないと、多少帯域幅は落ちてもサイドチャネル自体は
生きているように思える。

しかもモニタするプロセスは条件に合うタイミングを気長に待てばよく、
対象プロセスの全ての動作タイミングでサイドチャネルをマスクできる
アクティビティがかかることを保証しないといけない。
0085名無しさん＠お腹いっぱい。2005/05/21(土) 14:56:27
>>84
> しかもモニタするプロセスは条件に合うタイミングを気長に待てばよく、

そのタイミングをどうやって知るの？キャッシュのページエラーを起こしているのが
SSLの秘密鍵処理であってapacheによるIOに絡んだキャッシュ消費やJavaVMに
よる巨大ヒープへのアクセスによるものじゃないことが、どうやってわかる？
ユーザーランドで得られる情報じゃ粒度が全然合わないと思うけど・・・
0086名無しさん＠お腹いっぱい。2005/05/21(土) 15:01:10
知る必要があるの?
エラーが入ってたら捨てて次回を待てばいいのでは?
0087名無しさん＠お腹いっぱい。2005/05/21(土) 16:22:31
>>86
> エラーが入ってたら捨てて次回を待てばいいのでは?

エラーかどうかをどう判定する？
観測できるのは各命令のレイテンシーだけだよ。
そのレイテンシーがもう1つの仮想プロセッサで実行されている
SSLのコードの特定のスレッドの影響であることをどうやって知ることができる？
0088名無しさん＠お腹いっぱい。2005/05/21(土) 17:01:21
>>87
もう一度だけヒント。知る必要あるの?


0089名無しさん＠お腹いっぱい。2005/05/21(土) 17:08:56
エラーを別のものと勘違いしてるもより
0090名無しさん＠お腹いっぱい。2005/05/22(日) 00:21:28
>>85の言うエラー（ページエラー、キャッシュミス。
そもそもこれがあるかないかで1bitの情報を得る）と
>>86の言う「エラー」の意味が食い違っていると思う

>>86に質問
盗聴プロセスを走らせて、「011000100010100」というbit列を手に入れたとき
それがOpenSSLの秘密鍵の部分情報なのか、apacheプロセスのディスクIOに
よるものなのか、どうやって判定すればいいの？
0091名無しさん＠お腹いっぱい。2005/05/22(日) 03:45:51
>>88
あのー、君、盗聴の方法をちゃんと理解してる？
0092名無しさん＠お腹いっぱい。2005/05/22(日) 03:59:48
そういえばキーボードロガーのキーストローク記録からキャッシュカード番号の入力を特定するってどうやってるんだろ。
0093名無しさん＠お腹いっぱい。2005/05/22(日) 16:11:16
キャッシュカードの番号と一緒に名前とか入れるだろうから、
その前後にあるそれらしい数字を探せば特定できるじゃん。
0094名無しさん＠お腹いっぱい。2005/05/22(日) 18:23:45
インテル最悪ッｽ
0095名無しさん＠お腹いっぱい。2005/05/22(日) 19:35:41
このスレに限って「鼬買い」とか言われないのはどうしてですか?
0096名無しさん＠お腹いっぱい。2005/05/22(日) 21:00:39
UNIX板は雑談スレ建て放題ですから
0097名無しさん＠お腹いっぱい。2005/05/22(日) 21:15:49
そう。夜11時から朝8時までは、スレ建て放題
0098名無しさん＠お腹いっぱい。2005/05/22(日) 22:47:01
...こんなでうごくだろうか?
とりあえずｺﾝﾊﾟﾙしてみよう。

--- kernel-source-2.6.11/arch/i386/kernel/cpu/common.c 2005-03-02 16:37:47.000000000 +0900
+++ kernel-source-2.6.11.hoge/arch/i386/kernel/cpu/common.c 2005-05-22 22:38:12.374133296 +0900
@@ -446,13 +446,16 @@

if (!cpu_has(c, X86_FEATURE_HT))
return;
-
+#if 0
cpuid(1, &eax, &ebx, &ecx, &edx);
smp_num_siblings = (ebx & 0xff0000) >> 16;

if (smp_num_siblings == 1) {
printk(KERN_INFO "CPU: Hyper-Threading is disabled\n");
} else if (smp_num_siblings > 1 ) {
+#endif /* 0 */
+ smp_num_siblings = 2;
+
index_lsb = 0;
index_msb = 31;

@@ -477,7 +480,9 @@

printk(KERN_INFO "CPU: Physical Processor ID: %d\n",
phys_proc_id[cpu]);
+#if 0
}
+#endif /* 0 */
}
#endif
0099名無しさん＠お腹いっぱい。2005/05/22(日) 23:09:37
なんかものすごく板違いされた悪寒
0100名無しさん＠お腹いっぱい。2005/05/22(日) 23:29:27
そう？いいんじゃないここで
0101名無しさん＠お腹いっぱい。2005/05/23(月) 00:12:00
えーt、戻り値をつかっているので、cpuid()は実行しないとだめの、もよう。

Linux version 2.6.11 (root@orz) (gcc バージョン 3.3.6 (Debian 1:3.3.6-5)) #1 SMP Sun May 22
23:06:58 JST 2005
...
Kernel command line: BOOT_IMAGE=orz ro root=302 acpismp=force
...
Initializing CPU#0
...
CPU0: Intel(R) Pentium(R) 4 CPU 2.53GHz stepping 07
per-CPU timeslice cutoff: 1463.07 usecs.
task migration cache decay timeout: 2 msecs.
Total of 1 processors activated (5013.50 BogoMIPS).
WARNING: 1 siblings found for CPU0, should be 2

警告された...しかし!!

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.53GHz
stepping : 7
cpu MHz : 2533.874
cache size : 512 KB
physical id : 0
siblings : 2 <-- 注目!!

...しつれいしますた。巣に帰ります。
0102名無しさん＠お腹いっぱい。2005/05/23(月) 02:15:30
てゆーか、単に表示を変更しても意味ないような。。。
0103名無しさん＠お腹いっぱい。2005/05/23(月) 10:27:52
実際の被害報告ってあります？
0104名無しさん＠お腹いっぱい。2005/05/23(月) 10:39:49
てゆーか、お前FreeBSDのパッチ読んでないだろ……
0105952005/05/24(火) 23:06:22
>>96-97 いや、建て放題でも鼬買いは鼬買いと言われるでしょう。
最近は自治厨がいなくなったのかな。
0106名無しさん＠お腹いっぱい。2005/05/26(木) 09:49:23
0107名無しさん＠お腹いっぱい。2005/06/07(火) 20:56:07
全然よくわからないんだけど、
セグメンテーションでは防げないのか？＞メモリアクセス

ユーザプロセスがLDTを自由に作成できるなら話は別だけど
普通はメモリのアクセス範囲って決まってるものじゃないの？
0108名無しさん＠お腹いっぱい。2005/06/08(水) 06:57:11
全然深刻だと思えない。
0109名無しさん＠お腹いっぱい。2005/07/17(日) 08:52:19
実際のシステムではノイズが大きすぎて実用にはならないな。

論文読んでみて、
- cache miss を使った covert channel の構築するという発想
- それを実際に実現したプログラミング力
- ルーチンパターンから鍵を推定する数学力
に、ただただ感心した。コリンきゅんすげー、自分とおないどしなことに orz
0110名無しさん＠お腹いっぱい。2005/07/18(月) 08:17:53
エマさーーーーーーーん
■ このスレッドは過去ログ倉庫に格納されています