すでにretpolineがあるのにインテルはIBRSみたいなゴミを突っ込んできたとlinuxはお怒りなのです > So the IBRS garbage implies that Intel is _not_ planning on doing the right thing for the indirect branch speculation.
That's part of the big problem here. The speculation control cpuid stuff shows that Intel actually seems to plan on doing the right thing for meltdown (the main question being _when_). Which is not a huge surprise, since it should be easy to fix, and it's a really honking big hole to drive through. Not doing the right thing for meltdown would be completely unacceptable.
So the IBRS garbage implies that Intel is _not_ planning on doing the right thing for the indirect branch speculation.
by
Anonymous Coward
on 2018年01月23日 20時17分
(#3349604)
> The patches do things like add the garbage MSR writes to the kernel entry/exit points. That's insane. That says "we're trying to protect the kernel". We already have retpoline there, with less overhead.
まあインテルが批判を回避するために作ったゴミだからな仕方ない (スコア:5, 参考になる)
あのパッチはインテルが CPU の修正を敢えて使わせないために作ったゴミなので Linus が怒るのは仕方ないな。
誤解前提で簡略化して言うと、今回の脆弱性は本質的にCPUの問題なのでマイクロコードで修正すべきなのだけど、素直に修正してしまうと明らかに性能劣化してしまう。それで intel は linux カーネルからオンにしない限りその修正を有効にしないようなパッチを突っ込もうとしている。
CPU の問題を linux カーネル開発者や利用者に責任転嫁する機能だけしかないパッチを入れようとしているので開発者から見たらゴミ。
一方で、利用者から見ればセキュリティ問題を自分で判断して、敢えて使わない選択肢があるという意味で利点がないわけではない(推奨できないけど、速度優先でセキュリティを犠牲にする選択肢が残るということ)
＃ちなみに Redhat とかのOSベンダーは、インテルからパッチもらって先に当ててしまっているので一般ユーザの立場では特に気にする必要無し。
Re:まあインテルが批判を回避するために作ったゴミだからな仕方ない (スコア:2, 興味深い)
●インテルの素敵な計画
1) meltdown/spectre 対策用のマイクロコード作ってやったぞ。これデフォルトでオンにしたら、
CPU のバグフィックで性能劣化したって訴えられると困るので、デフォルトでオフな。
2) ほら linux kernel からマイクロコードの機能を有効にするためのパッチ書いたぞ。喰え。
Redhat: パッチ食べました(王様の服は素敵です)
Ubuntu: パッチ食べました(大人の対応大事です)
...
3) 「新しい linux カーネルでセキュリティ機能をオンにすると遅くなりますが、
古いカーネルやセキュリティ・オフなら遅くならないので CPU のせいではないです。
訴訟しないでください」
●インテルが計画外だったこと
1) 利用者「最新のマイクロコード使うと勝手にリブートするんだけど？」
2) Linus「何、このゴミ？ (王様は何で裸なの)」
Re: (スコア:0)
まあ、幼稚な文章を見ればわかるとおもうが、ぜんぜん違うから
すでにretpolineがあるのにインテルはIBRSみたいなゴミを突っ込んできたとlinuxはお怒りなのです
> So the IBRS garbage implies that Intel is _not_ planning on doing the right thing for the indirect branch speculation.
Re: (スコア:0, 参考になる)
前後まで含めるとこうだな
That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.
So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.
Hone
Re:まあインテルが批判を回避するために作ったゴミだからな仕方ない (スコア:3, 参考になる)
> The patches do things like add the garbage MSR writes to the kernel
entry/exit points. That's insane. That says "we're trying to protect
the kernel". We already have retpoline there, with less overhead.
問題となっているのは間接分岐予測なのだが、retpoline
https://support.google.com/faqs/answer/7625886 [google.com]
は分岐予測をオンにしたまま小さなトリックで対策するのに対し、
IBRS(Indirect Branch Restricted Speculation)はその名の通り分岐予測に制限をかけるので性能が落ちる
おまけにカーネルの入り口出口にMSR(Machine State Register)に書き込みをする
悪用されれば何をされるかわからない
それで激おこぷんぷん丸なのだ
元コメの幼稚な書き込みはデタラメだから
Re: (スコア:0)
半端な知識で書いてるなあ。現在 retpoline だけで対策できてると思ってるのかな？
それなら reject して終りな案件であって、もめる要素はないのに。
もう少し背景を調べれば元コメの言ってることも理解できると思うよ。
（まあ元コメは省略し過ぎなので酷いと思うけど）
Re: (スコア:0)
メールの中で読めた一部だけ拾っただけで IBRS が何で retpoline が何かわかってないだろう？
あと IBRS と retpoline の提案時期と実装順序とかも調べてみると良いかと。
まあ、とりあえずメール全文読んで、できたら前後スレッドとかも読んでみろ。
Re: (スコア:0)
で、IBRSって何の略で、retpolineはいつ提案されたもので、それぞれいつ実装されたものなの? retpolineは完全なのかな?
論破されたくないから読めないLKMLを延々コピペしたのに、やっぱり読めない調べられない理解できないのかな?
Re: (スコア:0)
で、具体的な指摘はどこなの？
できないの？
Re:まあインテルが批判を回避するために作ったゴミだからな仕方ない (スコア:1)
IBRSはretpolineと同じ機能を実現するものであると考えている
retpolineがあるのにIBRSが提案されている表向きの理由を理解していない
MSRへの書き込みを含めたIBRSの動作にリーナスが異論を唱えている理由を誤って推測している
これが具体的な指摘に当たらないし間違いじゃないというなら単なるキチガイの無敵論法でしかない