2018-05-11

Intelの古いマニュアルを誤読したために生じた脆弱性

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs | Hacker News

8086でスタックを切り替えるには、ssレジスターとspレジスターを両方変更する必要がある。しかし、ssレジスターだけを変更してまだspレジスターを変更していないときに割り込みがかかると問題だ。そこで、8086は粋なはからいによって例外的にこの問題に対処した。ssレジスターを変更した直後の1命令では割り込みが発生しない。仮に割り込みが起きたとしても1命令を実行するまでは遅延される。

もし、ssレジスターを書き換えた直後の1命令でカーネルモードに入った場合、この粋なはからいが問題になる。カーネルモードに入ったあと、カーネルコードを1命令たりとも実行していない段階で割り込みが発生する可能性があるからだ。しかも実行はカーネルモードだ。

2 comments:

abo junghichi said...

> カーネルモードに入ったあと、カーネルコードを1命令たりとも実行していない段階で割り込みが発生する可能性があるからだ。
GHz単位で動く近年のプロセッサでは、外部デバイスやタイマーなどの割り込みでこの脆弱性を踏む可能性は低いです。しかしネタ元が指摘しているように、デバッグ機能を使えば、この可能性を100%まで高めることができます。命令単位でのデバッグの実現のために、命令単位の割り込みが実装されているからです。

Anonymous said...

ハードウェアブレークポイントを使って設定できるブレークポイントの数には限りがあるので、ソフトウェアによるブレークポイント実装はどのOSでも有効にになっています。
そういう意味で、ハードウェアブレークポイント機能の利用は必須ではありません。
今回の件は、セキュリティを重視したというよりは、単にマンパワーが足りてなくて不可欠とまでは言えない機能の実装を省いたってだけかもしれませんね。
OpenBSDとカーネルの構造が似ている NetBSDもnot affectedになってますし。