すでに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.
https://access.redhat.com/solutions/3315431 [redhat.com] >The latest microcode_ctl and linux-firmware packages from Red Hat do not include resolutions > to the CVE-2017-5715 (variant 2) exploit. Red Hat is no longer providing microcode to addre
まあインテルが批判を回避するために作ったゴミだからな仕方ない (スコア: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の動作にリーナスが異論を唱えている理由を誤って推測している
これが具体的な指摘に当たらないし間違いじゃないというなら単なるキチガイの無敵論法でしかない
Re: (スコア:0)
インテルが日本企業だったら潰れるまでむしられるんだろうけど、アメリカ企業だからこんな対応でも何でもないんだろうね。
Re: (スコア:0)
経産相がリコール命令出すべき
Re: (スコア:0)
アメリカ企業だということよりも、イスラエルの資本が多く入っていて、工場をイスラエルに持ってたり、多額の資金援助をイスラエル政府に行ってきてる方が大きな理由じゃないですかね。
アメリカの場合、イスラエルロビーの政財界への影響力が物凄く大きいですから。
イスラエル系の大企業は、別格と言うか、議会や役所も下手につつけない。
Re: (スコア:0)
なんでもない声をアメリカ人が言ってるところを見たことがないだけで、なんでもないわけないじゃん。
Re: (スコア:0)
利用者から見て利点があるなら開発者にとってゴミではないのでは?
Linuxは「利用者なんて知ったこっちゃねぇ。」ってポリシーの元に開発されているわけじゃない(と思ってる)
怒ってる理由はパッチの質の悪さでしょ
Re:まあインテルが批判を回避するために作ったゴミだからな仕方ない (スコア:3, 興味深い)
CPU の機能(分岐予測)をカーネルから OFF/ON させるなんて筋が悪過ぎ。
何のためにそんな提案してんだ?
CPU の性能劣化を胡麻化したいだけじゃないのか?
というものです。コードの質とかじゃなくて、根本的な手段が酷い。
Re: (スコア:0)
利用者から見た利点なんてないしゴミです。
Re: (スコア:0)
それがさ、読めない全文コピペしてる人が一番理解してなさそうなところだけど、問題はパッチじゃないんだよねえ。
このパッチってMeltdown攻撃そのものに対策するコードじゃなくて、IBRSを制御するコードだろ? IBRSっていうのは…
Re: (スコア:0)
IBRSっていうのはソフトだと思ってるでしょ?
Re: (スコア:0)
他人を無暗にクズ扱いするのは人として良くないが、「説明を無暗に省略するのは悪手」というのもそれはそれで正しい指摘だと思うよ。
RedHatはパッチ取り下げ済み (スコア:0)
>>#ちなみに Redhat とかのOSベンダーは、インテルからパッチもらって先に当ててしまっているので
>>一般ユーザの立場では特に気にする必要無し。
RedHatは01/03にはパッチ取り下げて元に戻してるみたいですね。CVE-2017-5715 (variant 2)のパッチ
はCPUベンダーから入手してあててくれ、と。
https://access.redhat.com/solutions/3315431 [redhat.com]
>The latest microcode_ctl and linux-firmware packages from Red Hat do not include resolutions
> to the CVE-2017-5715 (variant 2) exploit. Red Hat is no longer providing microcode to addre