停滞ないし凋落の激しい電機業界にあって、負け組に分類されて久しく、ジリ貧ながらもリストラを繰り返す事で致命的な損失は回避し、しぶとく生き残って来たNECが、来年度にまたしても3000人をリストラするんだそうです。
対象は国内で、通信機器等のハードウェア部門及び間接部門。ハードはともかく、間接部門なんて過去のリストラで削りに削って来た筈で、今更そんなに余剰があるのか、いささか疑問を感じないではないですが、計画ではそうなっているとのこと。
そして、今後注力する分野は、お決まりのSI関連です。プロダクトが不採算に陥った電機メーカーが、ITサービス関連に注力する、というのは判を押したように何処も大体同じなわけですが、それだけだとジリ貧、という事で他社との差別化のために挙げられたのが顔認証です。海外の防犯向けを拡販して主力に育てるつもりだとか。
しかし、顔認証を含むNECのセキュリティ関連事業の売上高は年400億程度、NECの売上高の2%にも届いていないのです。これを主力に育てる、というのは、数年の内に少なくとも数倍以上に成長する、と言っているに等しいわけですが、特に最近特別な新製品が生まれたわけでもないのに、これからそんな急成長する、と言われても、率直に言って現実性に乏しいものと言わざるを得ません。
そもそも、これまでの市場や社会の動向から見て、顔認証にそこまでのニーズがあるかどうかも明らかではないわけで。というか、顔認証の導入で何らかの成功を得た例というのが殆どないのですね。失敗とか無駄に終わったとかいう話なら山程あるのですが。
実際、過去様々なところで行われた監視カメラ等による指名手配犯検挙等のサーベイランスの実験も、成功したという話は皆無でもありますし、国内空港への導入に際しても、実験で散々な結果が出て一度は頓挫したのを、多分に政治的に無理やり復活させてねじ込んだという有り様です。一部アミューズメントパーク等のゲートでの認証に採用されてはいますが、そのようなゲートを、莫大なコストをかけてまで導入する事が、必然的もしくはそこまでいかずとも自然と言えるようなシチューションが果たしてそんなにあるものか、疑問を抱かずにはいられないのです。
結局のところ、訴求するために必要な類の実績が全く足りていない、というか殆ど皆無なのが問題なのであって、それを解決しない事には成長も何もあったものではない、のではないかと。
もっとも、その辺の非情な現実は当のNEC自身が一番良く承知している筈ですし、自分でもそんな夢物語は信じておらず、リストラをするにあたり、夢も希望もなくただ削減、という形になる事を回避するため、体裁を取り繕う建前を探したところ、顔認証位しか使えるものが無かった、というだけの事なのかもしれませんけれども。
だとしたら、一番大変なのは、具体的な見通しも何も無いままに、社全体の未来を背負う、そんな無茶な目標を押し付けられる羽目になるだろう顔認証部門の開発・営業の担当者たちなのかもしれませんね。どうしろっていうんだよ、というところでしょうか。といって、それらの部門は、長い間、近い将来はこう成長する、こんな可能性がある、と色々な建前を掲げ、それで少なくない運転資金や利益を得て来ている筈で、その山のように積み上がったコミットメントを果たす責任はあるわけです。そうである以上、無謀だとしても今更放棄や撤退は許されない、それは仕方ないところではあるのでしょう。
ただ、その辺は全てNECの内部の事情に過ぎません。必要性もメリットもない顧客に押し売りするような真似だけはしないで頂きたいものです。無論、必要性とメリットが十分にあり、かつデメリットが許容可能であり、コストとも釣り合う、というのを顧客がよく理解し納得して、勿論メーカー側から性能や精度その他ごまかしや隠蔽が無い、というのであれば何も問題はないのですが。
ＮＥＣ、来年度にも国内３千人削減へ 海外展開に出遅れ
[関連記事 [IT] 顔認証による入出国実証実験結果の出鱈目さに脱力]
[関連記事 [IT] 顔認証による入出国自動化に性懲りもなく復活の試み]
[関連記事 [IT] 顔認証による入出国自動化、廃案]
1/30/2018
1/28/2018
[biz] 無法と無謀の必然、相次ぐ暗号通貨取引所の破滅
Mt.Goxの再来、になるのでしょうか。暗号（仮想）通貨取引所大手Coincheckにおける大規模な通貨窃取、からの取引停止の件です。丁度派手にTVCM等を打っていたところが即、という事で、CMにコメディアンを起用していた事と相まって、出来の悪いコントを見せられたような微妙な気分にさせられてしまいました。被害を受けた人は実質的に詐欺に遭ったも同然につき全く笑えないでしょうけど、多分に博打ですったとでも思って諦めるしかないんじゃないでしょうか。ご愁傷さまです。
しかし、まだ本件の全容は殆ど明らかになっていません。そもそも同取引所の運営実体はあまり公に明かされておらず、そのため不明な事だらけだし、おそらくは杜撰なその実態を公表する事を渋っているのだろう同社が説明不足な事もあって、様々な憶測が飛び交い、事態はますます混乱を深める酷い有り様です。
とはいえ、現時点で明らかになっている事実、すなわち同社が保管していた暗号通貨XEM（NEM）のほぼ全てである約5億2600万単位が同取引所から失われた事、また他の通貨についても同様に失われた可能性がある事、そしてXEM以外の全ての暗号通貨や日本円も含め、全ての資産についてユーザが引き出せなくなっている事等からだけでも、既にMt.Goxの際の被害額・規模を超える大惨事に至っている事は明らかであると言えるでしょう。
（追記： XEM以外の通貨につき、XRP（Ripple）約1億100万も消失したとの事です。）
本件の責任が専らCoincheck社に帰するものである事は疑いようがありません。では、今後追及されるだろうその内容はどのようなものでしょうか。
民事的にはどうか。まず前提として、取引所における暗号通貨は、法的には一般に所有者たるユーザーからの寄託（もしくは信託）物に準ずるものと解されているようです。そうであれば、今回失われたものも含め、Coindesk社が管理していた暗号通貨の所有権はユーザーにあり、同社はそれを預かり、ユーザの指示に従う形で取引を代行していたに過ぎない事になります。
そして、受寄者たる同社には善管注意義務があるところ、同社がその暗号通貨の管理にあたり、一般に標準とされる程度の盗難防止措置を取っていなかった事は既に明らかであり、その点で注意義務違反が認められます。従って、ユーザには、被った被害につき同社に対する損害賠償請求権が生じています。
また、寄託者たるユーザは、寄託物（この場合は預かっている暗号通貨）につき返還請求権を有しており、任意に返還を請求出来、同社はそれに応じる義務があります。しかし同社はユーザの返還請求に応じておらず、その点でも違法性が認められます。当然ながら返せない、では済みません。返還不能になった通貨等につき、相当額の賠償をする義務が生じます。また、返還が妨げられた事で生じた機会損失等についての損害賠償請求権も生じ得ます。もっとも、その返還停止にシステムの管理上の必要性があり、一時的な、合理性の認められる範囲に留まる限り、ただちに生じているとは言えないかもしれませんけれども。
それらのもろもろの請求権を合わせると、同社の負っている債務は、少なくとも600億円を超え、XRP以外の通貨への波及の有無とその程度や規模次第でさらに膨れ上がる可能性もある巨大なものになっているわけです。同社がそれを支払えるか否かは不明ですが、社員数は100人に満たず、主要な出資元がベンチャーキャピタルであるという同社にその規模の保証金や資本金があるとは考えづらく、その支払いは極めて難しいと考えるべきでしょう。被害を被った方々には酷な話ではありますが。
そのような、後始末もままならない状況では、代表が会見で語ったように、事業を継続する事は殆ど不可能でしょう。何らかの方法で失われた通貨を取り戻す事に奇跡的に成功するのでもない限り、破綻は避けられないものと思われます。破綻した後、再生するのか、清算に追い込まれるのかはわかりませんが、只でさえシステムの十分な整備が出来ない、と泣きを入れているような状態ですし、再生しようとしても金融庁の登録審査に通らない可能性も高く、事実上は殆ど絶望的と言っていい状況にあるのではないでしょうか。
刑事的にはどうでしょうか。現時点で刑事的に明確に違法と言える事実は無いようです。CM等で一般の顧客を広く誘引し始めた矢先の話のため、取り込み詐欺を疑う向きもありますが、流石にその可能性は低いでしょう。ただ、前例として取り上げられているMt.Goxの件では、代表者が巨額の資金を着服していた事が後になって明らかとなり、代表者は逮捕されるに至りました。第3者に監視も管理もされておらず、やろうと思えばいくらでも内部から同様の犯罪を行う事は容易であっただろうCoindeskに同様の嫌疑がかかるのも致し方のないだろうところ、今後は程度は兎も角としてある程度司法の捜査対象となる事もあるでしょう。逆に言えば、それまでは刑事的に責任を追及される事はないものと思われるわけです。
同社は公の管理も監視もされていない私企業であり、その取引所にも一般にこの種の、巨額の金融財産を預かり、その取引を仲介する場として当然に備えられるべき、その資産を管理・保全する仕組みもなく、また今回のような被害が発生した際に備えた引当金等も（おそらくは）皆無に等しかったらしい、という、およそあり得べからざる運営実体が明らかになってきています。当然、被害に遭った顧客への補償など期待出来よう筈もないし、それ以前に残った（はずの）通貨等の資産を払い戻す事もままならない有り様は、欲をかいた顧客の自己責任、で片付けるにはいささか常軌を逸し過ぎているように思われるところです。
無責任も甚だしく、いっそ無謀と言ってもいいだろうその信じ難い運営実態に愕然とさせられると共に、そもそも、何故そのような業者が公然と巨大な取引所を運営する事が許されているのか、疑問を抱かずにはいられません。Mt.Goxの件をはじめ、取引所の杜撰な運営に起因して顧客の資産が失われる例は枚挙に暇がない程であり、その対策の必要性は十分に認識されている筈なのですが。
思い当たる要因がないわけではありません。元々、新規の技術に基づく新種の対象を取引する場であるために、管理・規制のためのノウハウもなく、法制も追いついていない、それもおそらく要因に含まれているものと思われます。しかし、暗号通貨は新規の資産であると言っても、その性質は既存の、電子的に取引される金融資産のそれと類似しており、一般的な、実際の管理・運用におけるノウハウが無いわけではありません。にも関わらずそれらを全く踏まえずに、このような杜撰な運営が横行する、というのは、ノウハウ不足や法制の不備以外に主たる要因があるものと言うべきでしょう。
すなわち、何の規制もない事をいい事に取引所の開設・運営に乗り出した企業、またその人員の殆どが、金融関連の取引について、とりわけその法制面についての素人同然であり、そのため一定の法関連の知識があれば当然に認識するだろうリスクに鈍感で、それらへの手当を怠り、あるいは意図的に放置しさえする事の方が主たる原因であるように見えます。そうでなければ、どうしてかように無反省に同じ過ちを繰り返す事が出来るというのでしょうか。
本来言うまでもない事ですが、企業とその人員には、その営む事業の規模や社会における位置づけ、取引の内容等に応じて、当然に果たすべき責任があるわけです。その責任は、ベンチャーだから、若いから、人出が足りないから、等と言って放り出す事が許されるものではないし、本件取引所のような巨大な利害が動き、その規模に応じた重い責任を伴う事業であればなおさらです。分不相応な事業に手を出した愚かさを嘆くのは勝手ですが、自分たちの失敗によって他者に生じさせた被害の責任は当然取らなければなりません。その結果が、破綻すなわち企業としての死であったとしても、甘受する他ないでしょう。
その責任を軽んじ、あるいはそもそもその負うべき責任も、そのために必要な知識やリソースも認識せず、ただ無謀のままに事業を起こしたというのであれば、その失敗と破綻は必然の結果であったものと言う他ないわけです。
しかし、関連する界隈では、今回の件があってなお、反省のち修正しようという向きが殆ど見られないのは流石に。。。馬鹿は死んでも治らない、というか、救い難いにも程があると思うのです。暗号通貨と、その他の資産との相関が低く、通貨関連で破綻があっても経済にはあまり影響しない点は救いと言うべきなのか、だから歯止めがかからないのだと呆れるべきなのか。まあ、被害を蒙りたくなければ関わらないでおけばいいだけ、その他のバブル等よりはマシなのかもしれませんね。他人事としても見るに耐えない、というのはもうどうしようもないとして。
[関連記事 [note] 仮想通貨バブルの狂気性について]
[関連記事 [biz] Mt.Gox消滅で俄に訪れたBitCoin崩壊の瀬戸際]
しかし、まだ本件の全容は殆ど明らかになっていません。そもそも同取引所の運営実体はあまり公に明かされておらず、そのため不明な事だらけだし、おそらくは杜撰なその実態を公表する事を渋っているのだろう同社が説明不足な事もあって、様々な憶測が飛び交い、事態はますます混乱を深める酷い有り様です。
とはいえ、現時点で明らかになっている事実、すなわち同社が保管していた暗号通貨XEM（NEM）のほぼ全てである約5億2600万単位が同取引所から失われた事、また他の通貨についても同様に失われた可能性がある事、そしてXEM以外の全ての暗号通貨や日本円も含め、全ての資産についてユーザが引き出せなくなっている事等からだけでも、既にMt.Goxの際の被害額・規模を超える大惨事に至っている事は明らかであると言えるでしょう。
（追記： XEM以外の通貨につき、XRP（Ripple）約1億100万も消失したとの事です。）
本件の責任が専らCoincheck社に帰するものである事は疑いようがありません。では、今後追及されるだろうその内容はどのようなものでしょうか。
民事的にはどうか。まず前提として、取引所における暗号通貨は、法的には一般に所有者たるユーザーからの寄託（もしくは信託）物に準ずるものと解されているようです。そうであれば、今回失われたものも含め、Coindesk社が管理していた暗号通貨の所有権はユーザーにあり、同社はそれを預かり、ユーザの指示に従う形で取引を代行していたに過ぎない事になります。
そして、受寄者たる同社には善管注意義務があるところ、同社がその暗号通貨の管理にあたり、一般に標準とされる程度の盗難防止措置を取っていなかった事は既に明らかであり、その点で注意義務違反が認められます。従って、ユーザには、被った被害につき同社に対する損害賠償請求権が生じています。
また、寄託者たるユーザは、寄託物（この場合は預かっている暗号通貨）につき返還請求権を有しており、任意に返還を請求出来、同社はそれに応じる義務があります。しかし同社はユーザの返還請求に応じておらず、その点でも違法性が認められます。当然ながら返せない、では済みません。返還不能になった通貨等につき、相当額の賠償をする義務が生じます。また、返還が妨げられた事で生じた機会損失等についての損害賠償請求権も生じ得ます。もっとも、その返還停止にシステムの管理上の必要性があり、一時的な、合理性の認められる範囲に留まる限り、ただちに生じているとは言えないかもしれませんけれども。
それらのもろもろの請求権を合わせると、同社の負っている債務は、少なくとも600億円を超え、XRP以外の通貨への波及の有無とその程度や規模次第でさらに膨れ上がる可能性もある巨大なものになっているわけです。同社がそれを支払えるか否かは不明ですが、社員数は100人に満たず、主要な出資元がベンチャーキャピタルであるという同社にその規模の保証金や資本金があるとは考えづらく、その支払いは極めて難しいと考えるべきでしょう。被害を被った方々には酷な話ではありますが。
そのような、後始末もままならない状況では、代表が会見で語ったように、事業を継続する事は殆ど不可能でしょう。何らかの方法で失われた通貨を取り戻す事に奇跡的に成功するのでもない限り、破綻は避けられないものと思われます。破綻した後、再生するのか、清算に追い込まれるのかはわかりませんが、只でさえシステムの十分な整備が出来ない、と泣きを入れているような状態ですし、再生しようとしても金融庁の登録審査に通らない可能性も高く、事実上は殆ど絶望的と言っていい状況にあるのではないでしょうか。
刑事的にはどうでしょうか。現時点で刑事的に明確に違法と言える事実は無いようです。CM等で一般の顧客を広く誘引し始めた矢先の話のため、取り込み詐欺を疑う向きもありますが、流石にその可能性は低いでしょう。ただ、前例として取り上げられているMt.Goxの件では、代表者が巨額の資金を着服していた事が後になって明らかとなり、代表者は逮捕されるに至りました。第3者に監視も管理もされておらず、やろうと思えばいくらでも内部から同様の犯罪を行う事は容易であっただろうCoindeskに同様の嫌疑がかかるのも致し方のないだろうところ、今後は程度は兎も角としてある程度司法の捜査対象となる事もあるでしょう。逆に言えば、それまでは刑事的に責任を追及される事はないものと思われるわけです。
同社は公の管理も監視もされていない私企業であり、その取引所にも一般にこの種の、巨額の金融財産を預かり、その取引を仲介する場として当然に備えられるべき、その資産を管理・保全する仕組みもなく、また今回のような被害が発生した際に備えた引当金等も（おそらくは）皆無に等しかったらしい、という、およそあり得べからざる運営実体が明らかになってきています。当然、被害に遭った顧客への補償など期待出来よう筈もないし、それ以前に残った（はずの）通貨等の資産を払い戻す事もままならない有り様は、欲をかいた顧客の自己責任、で片付けるにはいささか常軌を逸し過ぎているように思われるところです。
無責任も甚だしく、いっそ無謀と言ってもいいだろうその信じ難い運営実態に愕然とさせられると共に、そもそも、何故そのような業者が公然と巨大な取引所を運営する事が許されているのか、疑問を抱かずにはいられません。Mt.Goxの件をはじめ、取引所の杜撰な運営に起因して顧客の資産が失われる例は枚挙に暇がない程であり、その対策の必要性は十分に認識されている筈なのですが。
思い当たる要因がないわけではありません。元々、新規の技術に基づく新種の対象を取引する場であるために、管理・規制のためのノウハウもなく、法制も追いついていない、それもおそらく要因に含まれているものと思われます。しかし、暗号通貨は新規の資産であると言っても、その性質は既存の、電子的に取引される金融資産のそれと類似しており、一般的な、実際の管理・運用におけるノウハウが無いわけではありません。にも関わらずそれらを全く踏まえずに、このような杜撰な運営が横行する、というのは、ノウハウ不足や法制の不備以外に主たる要因があるものと言うべきでしょう。
すなわち、何の規制もない事をいい事に取引所の開設・運営に乗り出した企業、またその人員の殆どが、金融関連の取引について、とりわけその法制面についての素人同然であり、そのため一定の法関連の知識があれば当然に認識するだろうリスクに鈍感で、それらへの手当を怠り、あるいは意図的に放置しさえする事の方が主たる原因であるように見えます。そうでなければ、どうしてかように無反省に同じ過ちを繰り返す事が出来るというのでしょうか。
本来言うまでもない事ですが、企業とその人員には、その営む事業の規模や社会における位置づけ、取引の内容等に応じて、当然に果たすべき責任があるわけです。その責任は、ベンチャーだから、若いから、人出が足りないから、等と言って放り出す事が許されるものではないし、本件取引所のような巨大な利害が動き、その規模に応じた重い責任を伴う事業であればなおさらです。分不相応な事業に手を出した愚かさを嘆くのは勝手ですが、自分たちの失敗によって他者に生じさせた被害の責任は当然取らなければなりません。その結果が、破綻すなわち企業としての死であったとしても、甘受する他ないでしょう。
その責任を軽んじ、あるいはそもそもその負うべき責任も、そのために必要な知識やリソースも認識せず、ただ無謀のままに事業を起こしたというのであれば、その失敗と破綻は必然の結果であったものと言う他ないわけです。
しかし、関連する界隈では、今回の件があってなお、反省のち修正しようという向きが殆ど見られないのは流石に。。。馬鹿は死んでも治らない、というか、救い難いにも程があると思うのです。暗号通貨と、その他の資産との相関が低く、通貨関連で破綻があっても経済にはあまり影響しない点は救いと言うべきなのか、だから歯止めがかからないのだと呆れるべきなのか。まあ、被害を蒙りたくなければ関わらないでおけばいいだけ、その他のバブル等よりはマシなのかもしれませんね。他人事としても見るに耐えない、というのはもうどうしようもないとして。
[関連記事 [note] 仮想通貨バブルの狂気性について]
[関連記事 [biz] Mt.Gox消滅で俄に訪れたBitCoin崩壊の瀬戸際]
1/23/2018
[PC] Spectreパッチでさらに性能低下
IntelのやらかしたMeltdown、そのパッチ適用による壊滅的な性能低下の手当もままならない最中ではありますが、続いてSpectreのパッチもLinuxの主要ディストリビューションで配布されてしまいました。もうどうにでもなれ、と前回適用したサブPCでその性能への影響をベンチした次第です。
ベンチ対象はSandy世代のG630機、OSはUbuntu16.04LTSで、Spectreパッチ適用後のカーネルバージョンは4.4.0-112になります。
その結果は以下の通り。前回の表に追加されたafter2の列がSpectreパッチ適用後のベンチ結果で、2列目のafter1は前回掲載したMeltdownのみ適用時のスコア、3列目は両パッチ適用前、最後の列にはMeltdown適用前とafter2の比を記載しています。
総合スコアではMeltdown適用後(after1)からさらに数%のダウンとなりました。個別の項目では、システムコールオーバーヘッドがmeltdown後からさらに2割程低下し、シングルスレッドではついに元の1/5となる2割にまで落ちている他、パイプのスループットも同様に1割超低下して元の5割を割り込んでしまっています。
Meltdown適用時の落ち込みに比べればマシには違いありませんが、無視出来る程でもなく、やはり落胆は禁じえません。もうDB系はまともに使えませんね。ビジネスユーザではますますEpyc（Ryzen）等への乗り換えが進みそうです。もうすぐリリースされる予定のRyzen APUは、個人や小規模ユーザには非常に人気を集めるのではないでしょうか。私も時期を見て、可能な限り速やかに乗り換えたいと思います。
もはや待ったなしの現実がユーザに突きつけられる一方で、Intelが公開したマイクロコードにはPCを落としたり再起動出来なくさせたりするバグが発覚して適用中止を呼びかける事態にもなっていたり、それ以前にLinusをはじめとするLinuxのDeveloperコミュニティとの対立も悪化の一途を辿っていたりで、Intelの既存ユーザに関する限り、事態は解決どころか悪化するばかりです。それもこれもIntelが保身を図るべく性能低下を誤魔化そうとして中途半端かつ杜撰な対応をした事が主要因と言わざるを得ないわけで、もうこのまま地獄に落ちる他ないんじゃないかと。道連れにされる我々はたまったもんじゃありません。この状況を見る限り、Intelが事態を早期に解決出来るものとは到底期待出来ないし、やはりIntelを見限って乗り換えるユーザの大量発生は避けられないでしょう。それに伴うIntelに対する損害賠償請求はとんでもない事になりそうです。しかもその潜在的な被害は今以って拡大中という。。。
USN-3540-1: Linux kernel vulnerabilities
[関連記事 [PC] Meltdownパッチ適用後の性能低下が本当に酷くて困った（Linux）]
ベンチ対象はSandy世代のG630機、OSはUbuntu16.04LTSで、Spectreパッチ適用後のカーネルバージョンは4.4.0-112になります。
その結果は以下の通り。前回の表に追加されたafter2の列がSpectreパッチ適用後のベンチ結果で、2列目のafter1は前回掲載したMeltdownのみ適用時のスコア、3列目は両パッチ適用前、最後の列にはMeltdown適用前とafter2の比を記載しています。
総合スコアではMeltdown適用後(after1)からさらに数%のダウンとなりました。個別の項目では、システムコールオーバーヘッドがmeltdown後からさらに2割程低下し、シングルスレッドではついに元の1/5となる2割にまで落ちている他、パイプのスループットも同様に1割超低下して元の5割を割り込んでしまっています。
| 1-way | after2 | after1 | before | after2/before |
| Dhrystone 2 using register variables | 2706.5 | 2706.2 | 2706 | 1.00 |
| Double-Precision Whetstone | 666.5 | 666.4 | 666.3 | 1.00 |
| Execl Throughput | 900.9 | 898.9 | 1015.4 | 0.89 |
| File Copy 1024 bufsize 2000 maxblocks | 1400.8 | 1452.3 | 2190.2 | 0.64 |
| File Copy 256 bufsize 500 maxblocks | 961.6 | 980.9 | 1667.2 | 0.58 |
| File Copy 4096 bufsize 8000 maxblocks | 2770.7 | 2796.9 | 3638.1 | 0.76 |
| Pipe Throughput | 694.1 | 789.1 | 1544.4 | 0.45 |
| Pipe-based Context Switching | 418.5 | 428.9 | 482.8 | 0.87 |
| Process Creation | 944 | 925.4 | 1060.1 | 0.89 |
| Shell Scripts (1 concurrent) | 2304 | 2313.1 | 2470.2 | 0.93 |
| Shell Scripts (8 concurrent) | 3010.6 | 3028.5 | 3235.4 | 0.93 |
| System Call Overhead | 462.1 | 553.1 | 2369.4 | 0.20 |
| System Benchmarks Index Score | 1149.7 | 1187.2 | 1634.7 | 0.70 |
| 2-way | after2 | after1 | before | after2/before |
| Dhrystone 2 using register variables | 5408.1 | 5398.8 | 5408.7 | 1.00 |
| Double-Precision Whetstone | 1331.4 | 1329 | 1331.3 | 1.00 |
| Execl Throughput | 1978.6 | 1965.7 | 2213 | 0.89 |
| File Copy 1024 bufsize 2000 maxblocks | 2587.1 | 2639.1 | 3031.2 | 0.85 |
| File Copy 256 bufsize 500 maxblocks | 1774.5 | 1832.3 | 1990 | 0.89 |
| File Copy 4096 bufsize 8000 maxblocks | 4887.1 | 4791.5 | 5352.5 | 0.91 |
| Pipe Throughput | 1357 | 1568.3 | 3100.4 | 0.44 |
| Pipe-based Context Switching | 889.3 | 948.2 | 1632.1 | 0.54 |
| Process Creation | 1782 | 1818.4 | 2091.3 | 0.85 |
| Shell Scripts (1 concurrent) | 3441.3 | 3452.5 | 3749.8 | 0.92 |
| Shell Scripts (8 concurrent) | 3201.2 | 3211.3 | 3468.8 | 0.92 |
| System Call Overhead | 877.5 | 1018.8 | 3756 | 0.23 |
| System Benchmarks Index Score | 2082.3 | 2154.1 | 2831.9 | 0.74 |
Meltdown適用時の落ち込みに比べればマシには違いありませんが、無視出来る程でもなく、やはり落胆は禁じえません。もうDB系はまともに使えませんね。ビジネスユーザではますますEpyc（Ryzen）等への乗り換えが進みそうです。もうすぐリリースされる予定のRyzen APUは、個人や小規模ユーザには非常に人気を集めるのではないでしょうか。私も時期を見て、可能な限り速やかに乗り換えたいと思います。
もはや待ったなしの現実がユーザに突きつけられる一方で、Intelが公開したマイクロコードにはPCを落としたり再起動出来なくさせたりするバグが発覚して適用中止を呼びかける事態にもなっていたり、それ以前にLinusをはじめとするLinuxのDeveloperコミュニティとの対立も悪化の一途を辿っていたりで、Intelの既存ユーザに関する限り、事態は解決どころか悪化するばかりです。それもこれもIntelが保身を図るべく性能低下を誤魔化そうとして中途半端かつ杜撰な対応をした事が主要因と言わざるを得ないわけで、もうこのまま地獄に落ちる他ないんじゃないかと。道連れにされる我々はたまったもんじゃありません。この状況を見る限り、Intelが事態を早期に解決出来るものとは到底期待出来ないし、やはりIntelを見限って乗り換えるユーザの大量発生は避けられないでしょう。それに伴うIntelに対する損害賠償請求はとんでもない事になりそうです。しかもその潜在的な被害は今以って拡大中という。。。
USN-3540-1: Linux kernel vulnerabilities
[関連記事 [PC] Meltdownパッチ適用後の性能低下が本当に酷くて困った（Linux）]
1/10/2018
[PC] Meltdownパッチ適用後の性能低下が本当に酷くて困った（Linux）
未曾有の大災害になる事が確定しつつあるIntelのほぼ全CPUに発見されたハード修正不可の脆弱性Meltdown（CVE-2017-5754）について、ようやくLinuxでも修正版のカーネルがリリースされました。カーネルのバージョンはUbuntu17.10では4.13.0-25.29、Ubuntu16.04LTSでは4.4.0-109となっています。
(なお、Intel以外にもAMDとARMのCPUも対象となるSpectre（CVE-2017-5715,CVE-2017-5753）は未修正です。当初はこれについても適用されているのかと思っていましたが、確認したところこれは勘違いでした。今後改めてアップデートされる予定とのことです)
本件修正により、3割程度の性能低下が見込まれるものと見積もられている事もさる事ながら、本件で問題になっているような、通常変更が想定すらされていないコア部分の修正ですから、不具合を警戒して数日様子見をしたのですが、とりあえず私の環境下では性能低下以外の深刻な問題は発生していないようなので適用に踏み切ってみた次第です。勿論ロールバックのパスは確保した上で。
と言っても、いきなりメインの系列に入れるのは怖いので、サブ系のPC数台で試してみました。OSは全てLinuxで、そのうち2台がUbuntu17.10、1台がUbuntu16.04LTSです。CPUは、C2D世代、SandyBridge世代、Haswell世代が各1台です。
まず動作自体は特に問題は見られませんでした。いきなり落ちたり固まったりはしない、という意味です。そうでないと困るのですが、修正の内容が内容ですからね。実際WindowsではAMDの旧CPUについて深刻な副作用があったらしいですし。とそれはともかく。
で、問題の性能低下の件ですが、概ね3台とも同様の傾向を示しました。全て掲載するのも無駄が大きそうなので、とりあえず中間のSandy世代のCPU（G630）を積んだPCの分のベンチマーク結果を下記に掲載します。ベンチマークに用いたソフトは以前にも使った事のあるunixbench（5.1.3）で、シングルタスク（1-way）とマルチタスク（2-way）それぞれ、各項目について適用後（after）と適用前（before）及びその比を一覧表にしています。
結論から言えば、前評判そのままの酷さでした。総合スコアで見れば、シングルで27%、マルチで24%のダウンです。3割程度という事前情報に偽りなしですね。
個々に見ると、整数や浮動小数点等のコア内部で完結する処理については影響は無いのは当然として、やはりカーネルとのやり取りが発生する処理では大幅な落ち込みが見られます。
個別の項目で言えば、ファイルI/Oで1割から4割、またプロセス生成やシェルスクリプト全体について1割前後の減少。これだけでも、バッチ処理のスケジュールとか色々冷や汗が出る感じですが、まだこれはマシな方です。
特に悪いのは、パイプ処理とシステムコールです。パイプのスループットはおよそ5割にまで落ちていますし、システムコールのオーバーヘッドに至っては7割超の減少、すなわち1/4前後にまでパフォーマンスが落ちています。これはもう壊滅的と言っていいでしょう。
要するに、プロセス間通信だとか、ファイル関連の処理だとか、メモリの操作だとかが超絶遅くなる、という事です。それらの処理を多用する処理の代表たるデータベース系の性能が著しく低下する、というのも当然の結果と言うべきでしょう。
しかしこれは。。。事前情報として知らされてはいましたが、やはり実際に目の当たりにするとショックです。というか、これを甘受しなきゃいけないわけですが、率直に言って、はいそうですか、とは受け入れられないレベルです。実際問題、システム周りがこれだけスループットが落ちるというのは、DBはじめ大量のファイル等データを処理するタスクではシステムの再設計が必要になるし、処理時間の増大に合わせて運用のスケジュールも変更を強いられる事になりますが、それは勿論必ずしも容易な事ではありません。何より莫大なコストがかかります。増強するにしても、機材費は無論、スペースとか電力とかそのための資金はどうすんのさって話で。少なくとも採算の悪化は避けられませんし、資金が不足したり、採算が合わなくなってビジネスが立ち行かなくなる事業者が出ても全く不思議ではありません。
正直、運用面の変更で回避する方法を模索するか、それが無理ならAMD等の比較的マシなプラットフォームへの切替えを検討せざるを得ません。でもそんな予算ないよ、と。参りました。マジで頭が痛いです。というか、これはもうIntelから賠償等がなされなければ収まらないのではないでしょうか。要求される側のIntelについては自業自得としか評価しようがないし、むしろ地獄に落ちろと思う位なのですが。あーもう。
ところで、数日前にASUS製マザーボードJ3455M-E（Apollo lake）の新BIOSがリリースされていました。ようやくIntel ME,TXEの脆弱性に対応したのか、と思って適用してみたのですが、TXEは修正されておらず、適用しても判定結果はvulnerableのまま。糠喜び&徒労でした。どうもそっちは放置で、本件対応を優先させたようです。ユーザにとってはどっちも同じ位深刻な筈なんですが。。。あっちもこっちも無責任なやつらばかりで、もううんざりです。
（追記）
Ubuntu16.04LTSの最初に公開された対策済カーネル（4.4.0-108）には、ブート出来なくなる不具合があったんだそうで。私が適用した時点では既に4.4.0-109に差し替えられた後でしたが、危うく被害を被るところでした。把握していたわけではありませんが、少し待ったのが功を奏したという形になります。しかし本当に信用なりませんねCanonical。
[関連記事 [PC] Meltdownに続き、Spectre脆弱性発覚でCPU全陣営が一斉崩壊の危機]
[関連記事 [PC] ここ十年のIntel製CPUほぼ全てにハード修正不能でソフト対処後数割性能低下の脆弱性発覚]
[関連記事 [PC note] 今更ながらのApollo lakeが意外といい感じ]
[関連記事 [PC] 現行Intel製チップのファームウェアの大半に脆弱性発覚]
(なお、Intel以外にもAMDとARMのCPUも対象となるSpectre（CVE-2017-5715,CVE-2017-5753）は未修正です。当初はこれについても適用されているのかと思っていましたが、確認したところこれは勘違いでした。今後改めてアップデートされる予定とのことです)
本件修正により、3割程度の性能低下が見込まれるものと見積もられている事もさる事ながら、本件で問題になっているような、通常変更が想定すらされていないコア部分の修正ですから、不具合を警戒して数日様子見をしたのですが、とりあえず私の環境下では性能低下以外の深刻な問題は発生していないようなので適用に踏み切ってみた次第です。勿論ロールバックのパスは確保した上で。
と言っても、いきなりメインの系列に入れるのは怖いので、サブ系のPC数台で試してみました。OSは全てLinuxで、そのうち2台がUbuntu17.10、1台がUbuntu16.04LTSです。CPUは、C2D世代、SandyBridge世代、Haswell世代が各1台です。
まず動作自体は特に問題は見られませんでした。いきなり落ちたり固まったりはしない、という意味です。そうでないと困るのですが、修正の内容が内容ですからね。実際WindowsではAMDの旧CPUについて深刻な副作用があったらしいですし。とそれはともかく。
で、問題の性能低下の件ですが、概ね3台とも同様の傾向を示しました。全て掲載するのも無駄が大きそうなので、とりあえず中間のSandy世代のCPU（G630）を積んだPCの分のベンチマーク結果を下記に掲載します。ベンチマークに用いたソフトは以前にも使った事のあるunixbench（5.1.3）で、シングルタスク（1-way）とマルチタスク（2-way）それぞれ、各項目について適用後（after）と適用前（before）及びその比を一覧表にしています。
結論から言えば、前評判そのままの酷さでした。総合スコアで見れば、シングルで27%、マルチで24%のダウンです。3割程度という事前情報に偽りなしですね。
個々に見ると、整数や浮動小数点等のコア内部で完結する処理については影響は無いのは当然として、やはりカーネルとのやり取りが発生する処理では大幅な落ち込みが見られます。
個別の項目で言えば、ファイルI/Oで1割から4割、またプロセス生成やシェルスクリプト全体について1割前後の減少。これだけでも、バッチ処理のスケジュールとか色々冷や汗が出る感じですが、まだこれはマシな方です。
特に悪いのは、パイプ処理とシステムコールです。パイプのスループットはおよそ5割にまで落ちていますし、システムコールのオーバーヘッドに至っては7割超の減少、すなわち1/4前後にまでパフォーマンスが落ちています。これはもう壊滅的と言っていいでしょう。
要するに、プロセス間通信だとか、ファイル関連の処理だとか、メモリの操作だとかが超絶遅くなる、という事です。それらの処理を多用する処理の代表たるデータベース系の性能が著しく低下する、というのも当然の結果と言うべきでしょう。
| 1-way（シングル） | after | before | after/before |
| Dhrystone 2 using register variables | 2706.2 | 2706 | 1.00 |
| Double-Precision Whetstone | 666.4 | 666.3 | 1.00 |
| Execl Throughput | 898.9 | 1015.4 | 0.89 |
| File Copy 1024 bufsize 2000 maxblocks | 1452.3 | 2190.2 | 0.66 |
| File Copy 256 bufsize 500 maxblocks | 980.9 | 1667.2 | 0.59 |
| File Copy 4096 bufsize 8000 maxblocks | 2796.9 | 3638.1 | 0.77 |
| Pipe Throughput | 789.1 | 1544.4 | 0.51 |
| Pipe-based Context Switching | 428.9 | 482.8 | 0.89 |
| Process Creation | 925.4 | 1060.1 | 0.87 |
| Shell Scripts (1 concurrent) | 2313.1 | 2470.2 | 0.94 |
| Shell Scripts (8 concurrent) | 3028.5 | 3235.4 | 0.94 |
| System Call Overhead | 553.1 | 2369.4 | 0.23 |
| System Benchmarks Index Score | 1187.2 | 1634.7 | 0.73 |
| 2-way（マルチ） | after | before | after/before |
| Dhrystone 2 using register variables | 5398.8 | 5408.7 | 1.00 |
| Double-Precision Whetstone | 1329 | 1331.3 | 1.00 |
| Execl Throughput | 1965.7 | 2213 | 0.89 |
| File Copy 1024 bufsize 2000 maxblocks | 2639.1 | 3031.2 | 0.87 |
| File Copy 256 bufsize 500 maxblocks | 1832.3 | 1990 | 0.92 |
| File Copy 4096 bufsize 8000 maxblocks | 4791.5 | 5352.5 | 0.90 |
| Pipe Throughput | 1568.3 | 3100.4 | 0.51 |
| Pipe-based Context Switching | 948.2 | 1632.1 | 0.58 |
| Process Creation | 1818.4 | 2091.3 | 0.87 |
| Shell Scripts (1 concurrent) | 3452.5 | 3749.8 | 0.92 |
| Shell Scripts (8 concurrent) | 3211.3 | 3468.8 | 0.93 |
| System Call Overhead | 1018.8 | 3756 | 0.27 |
| System Benchmarks Index Score | 2154.1 | 2831.9 | 0.76 |
しかしこれは。。。事前情報として知らされてはいましたが、やはり実際に目の当たりにするとショックです。というか、これを甘受しなきゃいけないわけですが、率直に言って、はいそうですか、とは受け入れられないレベルです。実際問題、システム周りがこれだけスループットが落ちるというのは、DBはじめ大量のファイル等データを処理するタスクではシステムの再設計が必要になるし、処理時間の増大に合わせて運用のスケジュールも変更を強いられる事になりますが、それは勿論必ずしも容易な事ではありません。何より莫大なコストがかかります。増強するにしても、機材費は無論、スペースとか電力とかそのための資金はどうすんのさって話で。少なくとも採算の悪化は避けられませんし、資金が不足したり、採算が合わなくなってビジネスが立ち行かなくなる事業者が出ても全く不思議ではありません。
正直、運用面の変更で回避する方法を模索するか、それが無理ならAMD等の比較的マシなプラットフォームへの切替えを検討せざるを得ません。でもそんな予算ないよ、と。参りました。マジで頭が痛いです。というか、これはもうIntelから賠償等がなされなければ収まらないのではないでしょうか。要求される側のIntelについては自業自得としか評価しようがないし、むしろ地獄に落ちろと思う位なのですが。あーもう。
ところで、数日前にASUS製マザーボードJ3455M-E（Apollo lake）の新BIOSがリリースされていました。ようやくIntel ME,TXEの脆弱性に対応したのか、と思って適用してみたのですが、TXEは修正されておらず、適用しても判定結果はvulnerableのまま。糠喜び&徒労でした。どうもそっちは放置で、本件対応を優先させたようです。ユーザにとってはどっちも同じ位深刻な筈なんですが。。。あっちもこっちも無責任なやつらばかりで、もううんざりです。
（追記）
Ubuntu16.04LTSの最初に公開された対策済カーネル（4.4.0-108）には、ブート出来なくなる不具合があったんだそうで。私が適用した時点では既に4.4.0-109に差し替えられた後でしたが、危うく被害を被るところでした。把握していたわけではありませんが、少し待ったのが功を奏したという形になります。しかし本当に信用なりませんねCanonical。
[関連記事 [PC] Meltdownに続き、Spectre脆弱性発覚でCPU全陣営が一斉崩壊の危機]
[関連記事 [PC] ここ十年のIntel製CPUほぼ全てにハード修正不能でソフト対処後数割性能低下の脆弱性発覚]
[関連記事 [PC note] 今更ながらのApollo lakeが意外といい感じ]
[関連記事 [PC] 現行Intel製チップのファームウェアの大半に脆弱性発覚]
1/04/2018
[PC] Meltdownに続き、Spectre脆弱性発覚でCPU全陣営が一斉崩壊の危機
Intel製x86チップにこの程発覚した空前の規模の修正不能な脆弱性について、その分析が進み、詳細が明らかになってきたようです。
当初発表されたキャッシュ周りのアクセス制御に関する脆弱性はその内容もほぼ正確であった事が確定し、Meltdownと名付けられました。手が付けられないコア部分を炉心に、またその影響の大きさをその溶融に例えたという事でしょうか。洒落になってませんね。これはIntel製チップに殆ど特有のもので、その対処方法がOS側でカーネルのメモリ共有周りを無効化する他なく、そのパフォーマンスに対する副作用が甚大である点も同時に確定しています。
既に極めて深刻な事態である事は疑いようがありません。がしかし、さらに悪いことに、これに関連する他の脆弱性も発覚しています。大まかに言えばインストラクションの予測実行の際にMeltdown同様アクセス制御が働かず、権限外のエリアにアクセス出来てしまうというものです。こちらはその部分の名前（Speculative Execution）からSpectreと名付けられました。
Spectreも結果としてはMeltdownと同レベルの極めて深刻な脆弱性ですが、こちらがMeltdownとは別に問題とされる理由は、Intel以外のARMやAMDのチップにも存在するという点にあります。嘘だろ、と信じたくない向きも多いでしょうが、残念ながら既に実証コードも作成されています。すなわち、スマホ等も対象だという事なのです。
で、Spectreの発覚を待って、Intelが遅まきながら出したコメントがまた。その要点は2点で、曰く、まずホームユーザには殆ど影響はない。次に、Intelだけの問題ではない。以上。
・・・頭を下げる事すら出来ないんですかね。この期に及んで責任逃れ一択とか、ブチ切れたユーザからの集団訴訟という名の怒りの業火に焼かれて死ねばいいのです。
付け加えると、IntelのCEOであるBrian KrzanichはGoogleから本件の報告を受けた後の昨年11月に、その所有するIntelの株式を、CEOの資格要件として定款で定められた分を除いて売却していたとの事です。形式的には普通にインサイダー取引ですね。遺憾この上ない話です。なおGoogle曰くそのレポートをIntelに伝えたのは半年以上前だとか。少なくともそれ以降にIntelのCPUを購入したユーザに対しては本件のような重大な欠陥を隠して性能を喧伝した、すなわち詐欺を働いた格好になるわけです。
AMDはAMDで、敵失と見て調子に乗り、当社の製品は問題ない、性能を低下させるパッチは適用除外にしてほしい、等とまで言ったその日の内に同レベルの脆弱性が発覚してしまいました。その言い訳でも言うに事欠き、Spectreをして"小さな問題"等と言って矮小化しようとしています。相対的にマシなだけで、ユーザにしてみればどちらも50歩100歩でしかありません。Intelと一緒に逝ってしまえばいいのです。
両社のあまりの愚かな対応ぶりの陰に隠れてか、ARMは今の所比較的静かですが・・・実はここが一番ヤバいかもしれません。数が桁違いな上に、本件で問題なのはそのARMが専ら責任を負うべきアーキの設計の部分につき、全世界のメーカー各社から本件に関する責任を問われる、すなわち損害賠償等を請求されて然るべき立場にあるからです。言うまでもなく、それらをまともに請求されたら同社単体では耐えられません。親会社たるSoftBankに泣きつくしかないんでしょうけど、大人しく応じるSBでもないだろうし、さてどうするのやら。
一夜にして既存のCPU市場におけるほぼ全ての陣営が崩壊の危機に直面する事になった本件、ヤバいなんてもんじゃありませんね。これはもしかしてRISC-Vの下克上が来る？とか現実逃避の一つもしたくなります。
“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws
[関連記事 [PC] ここ十年のIntel製CPUほぼ全てにハード修正不能でソフト対処後数割性能低下の脆弱性発覚]
当初発表されたキャッシュ周りのアクセス制御に関する脆弱性はその内容もほぼ正確であった事が確定し、Meltdownと名付けられました。手が付けられないコア部分を炉心に、またその影響の大きさをその溶融に例えたという事でしょうか。洒落になってませんね。これはIntel製チップに殆ど特有のもので、その対処方法がOS側でカーネルのメモリ共有周りを無効化する他なく、そのパフォーマンスに対する副作用が甚大である点も同時に確定しています。
既に極めて深刻な事態である事は疑いようがありません。がしかし、さらに悪いことに、これに関連する他の脆弱性も発覚しています。大まかに言えばインストラクションの予測実行の際にMeltdown同様アクセス制御が働かず、権限外のエリアにアクセス出来てしまうというものです。こちらはその部分の名前（Speculative Execution）からSpectreと名付けられました。
Spectreも結果としてはMeltdownと同レベルの極めて深刻な脆弱性ですが、こちらがMeltdownとは別に問題とされる理由は、Intel以外のARMやAMDのチップにも存在するという点にあります。嘘だろ、と信じたくない向きも多いでしょうが、残念ながら既に実証コードも作成されています。すなわち、スマホ等も対象だという事なのです。
で、Spectreの発覚を待って、Intelが遅まきながら出したコメントがまた。その要点は2点で、曰く、まずホームユーザには殆ど影響はない。次に、Intelだけの問題ではない。以上。
・・・頭を下げる事すら出来ないんですかね。この期に及んで責任逃れ一択とか、ブチ切れたユーザからの集団訴訟という名の怒りの業火に焼かれて死ねばいいのです。
付け加えると、IntelのCEOであるBrian KrzanichはGoogleから本件の報告を受けた後の昨年11月に、その所有するIntelの株式を、CEOの資格要件として定款で定められた分を除いて売却していたとの事です。形式的には普通にインサイダー取引ですね。遺憾この上ない話です。なおGoogle曰くそのレポートをIntelに伝えたのは半年以上前だとか。少なくともそれ以降にIntelのCPUを購入したユーザに対しては本件のような重大な欠陥を隠して性能を喧伝した、すなわち詐欺を働いた格好になるわけです。
AMDはAMDで、敵失と見て調子に乗り、当社の製品は問題ない、性能を低下させるパッチは適用除外にしてほしい、等とまで言ったその日の内に同レベルの脆弱性が発覚してしまいました。その言い訳でも言うに事欠き、Spectreをして"小さな問題"等と言って矮小化しようとしています。相対的にマシなだけで、ユーザにしてみればどちらも50歩100歩でしかありません。Intelと一緒に逝ってしまえばいいのです。
両社のあまりの愚かな対応ぶりの陰に隠れてか、ARMは今の所比較的静かですが・・・実はここが一番ヤバいかもしれません。数が桁違いな上に、本件で問題なのはそのARMが専ら責任を負うべきアーキの設計の部分につき、全世界のメーカー各社から本件に関する責任を問われる、すなわち損害賠償等を請求されて然るべき立場にあるからです。言うまでもなく、それらをまともに請求されたら同社単体では耐えられません。親会社たるSoftBankに泣きつくしかないんでしょうけど、大人しく応じるSBでもないだろうし、さてどうするのやら。
一夜にして既存のCPU市場におけるほぼ全ての陣営が崩壊の危機に直面する事になった本件、ヤバいなんてもんじゃありませんね。これはもしかしてRISC-Vの下克上が来る？とか現実逃避の一つもしたくなります。
“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws
[関連記事 [PC] ここ十年のIntel製CPUほぼ全てにハード修正不能でソフト対処後数割性能低下の脆弱性発覚]
[PC] ここ十年のIntel製CPUほぼ全てにハード修正不能でソフト対処後数割性能低下の脆弱性発覚
このところハード周りに起因する深刻な脆弱性を連発し、広範囲に甚大な被害を撒き散らしているIntelが、またしてもやらかしてしまったようです。今回発覚したのもハードの脆弱性ですが、ここ十年程度の間に発売されたx86系CPUのほぼ全てが対象と、規模はさらに桁違い、またハード側での修正が不可能と非常に性質が悪く、その対処に伴う副作用も大きく、甚大な被害が予想されています。
まだパッチがリリースされていないのでその詳細は伏せられていますが、各所の情報を総合するに、今回の脆弱性の存在箇所はCPU内で、大まかに言って、各メモリ領域への権限に応じたアクセス制御に際し、その検証が対象のコードの実行前ではなく実行後に行われるため、本来ならアクセスが禁止されるメモリ領域に対して権限外からアクセスが出来てしまう、というもののようです。これを悪用すると、カーネル内部の保護情報、例えばパスワードだとかに権限外のプロセスからアクセス可能になり、原理的には攻撃者が何でも出来てしまう、というわけです。最悪ですね。
上記はあくまで現段階では推測に留まりますが、ハード側の修正は不可能、すなわちマイクロコードの変更では対処出来ないレベルの問題である点と、公開されているOS側での対処方法がカーネルサイドのメモリキャッシュのフラッシングだとかページングのランダム入れ替えだとか、要するにアクセス自体の防止は諦める事を前提に、対象エリアの情報を都度消すという、力技というか、極めて消極的な対処方法である点等を見るに、概ね間違っていないものと言って良いのでしょう。仮に違っていたとしても、およそ同種、同レベルの問題である事は間違いなさそうです。なんてお粗末な。
ハードの修正が不可能である以上、対処がソフト面による事はもう仕方ないのでしょう。ただその種のソフト的な対処は、パフォーマンス面で大きな負の影響を与える、副作用の大きいものにならざるを得ません。それも当然、OS側の処理をする度にキャッシュのクリアが入るとなれば、処理によってはキャッシュが無いも同然になり、低速な外部メモリ等へのアクセスが必然的に多発する事になるのですから。
仮にその方法のパッチを用いる場合、その導入前後で30%程度もパフォーマンスが低下する、との見積もりも出ています。個人ユースの事務処理のように、元々リソースをあまり使っておらず、余剰が常に十分あるような環境では許容出来なくもないかもしれませんが、余剰があるわけではない場合には深刻な問題となるでしょう。特に、仮想化等でリソース配分を動的に最適化しているDC等のクラウド系のサーバビジネスあたりには致命的なインパクトがある筈です。脆弱性を放置する選択肢は取り得ませんから、パッチを当てた瞬間不足に陥るべき数割のリソースを事前に増強する必要があるわけですが、当然ながらそのコストは大変な事になるのですし、Amazon、Google、Microsoftはじめ、各社とも今頃は大変な騒ぎになっていることでしょう。というか私も管理してるサーバのリソース見直しとか頭が痛い。。。どうしよう。
ユーザが対処に追われる一方、当の犯人たるIntelは、まだ何もアクションを起こしていません。生じた被害はここ十年に販売したCPU全部すなわち数億件レベルで言うまでもなく甚大、Intel側で修正は不可能なために被害を食い止める事も出来ず、そもそも現行製品も対象でアーキテクチャの根本的な見直しが必要になる以上、問題を認めた瞬間に全製品が販売停止から回収となり、かつソフト側の対処に伴う費用とそれで落ちる性能分の損害賠償or増強費用を合算した空前の規模の損害賠償責任が降りかかってくるわけで、そりゃちょっとどうしていいかわからなくなるのも無理はないとも思いますけれども。しかしだからといってだんまりを決め込んでもどうにもならないでしょうし、潔く腹を切るしかないのではないかと思うのですが、さてどうしてくれるんでしょう。
なお、Intel以外のCPUではどうかというと、AMDは問題ない旨リリースを出していますが、ARMは何か怪しいです。というのも、ARM向けにも同様のパッチが準備されている、という話が出ているからです。ARMも、となると、スマホやタブレット、各種IoTデバイス等、一気に対象が広がってしまい、只でさえ大変な本件の規模がさらに何倍、という惨事になってしまうわけですが。。。どうなってしまうんでしょう。というか、そうだとしたら、どうにかなるのかこれ？
先日のファームウェアの脆弱性についてもまだ解決されていないのに。。。私のところのサーバに使っているJ3455M-Eの対策済みBIOSはまだリリースの予定すら立っていないようです。こっちも同じ位洒落になりません。まあこっちはマザーボードメーカー（ASUS）の問題ではあるのですけど。
The mysterious case of the Linux Page Table Isolation patches
で、あっという間に横展開の調査も進み、本件に加えてさらに同種の脆弱性も発覚してしまいました。しかもこちらはARMやAMDのチップも対象に含まれています。
[続き記事 [PC] Meltdownに続き、Spectre脆弱性発覚でCPU全陣営が一斉崩壊の危機]
[関連記事 [PC] 現行Intel製チップのファームウェアの大半に脆弱性発覚]
まだパッチがリリースされていないのでその詳細は伏せられていますが、各所の情報を総合するに、今回の脆弱性の存在箇所はCPU内で、大まかに言って、各メモリ領域への権限に応じたアクセス制御に際し、その検証が対象のコードの実行前ではなく実行後に行われるため、本来ならアクセスが禁止されるメモリ領域に対して権限外からアクセスが出来てしまう、というもののようです。これを悪用すると、カーネル内部の保護情報、例えばパスワードだとかに権限外のプロセスからアクセス可能になり、原理的には攻撃者が何でも出来てしまう、というわけです。最悪ですね。
上記はあくまで現段階では推測に留まりますが、ハード側の修正は不可能、すなわちマイクロコードの変更では対処出来ないレベルの問題である点と、公開されているOS側での対処方法がカーネルサイドのメモリキャッシュのフラッシングだとかページングのランダム入れ替えだとか、要するにアクセス自体の防止は諦める事を前提に、対象エリアの情報を都度消すという、力技というか、極めて消極的な対処方法である点等を見るに、概ね間違っていないものと言って良いのでしょう。仮に違っていたとしても、およそ同種、同レベルの問題である事は間違いなさそうです。なんてお粗末な。
ハードの修正が不可能である以上、対処がソフト面による事はもう仕方ないのでしょう。ただその種のソフト的な対処は、パフォーマンス面で大きな負の影響を与える、副作用の大きいものにならざるを得ません。それも当然、OS側の処理をする度にキャッシュのクリアが入るとなれば、処理によってはキャッシュが無いも同然になり、低速な外部メモリ等へのアクセスが必然的に多発する事になるのですから。
仮にその方法のパッチを用いる場合、その導入前後で30%程度もパフォーマンスが低下する、との見積もりも出ています。個人ユースの事務処理のように、元々リソースをあまり使っておらず、余剰が常に十分あるような環境では許容出来なくもないかもしれませんが、余剰があるわけではない場合には深刻な問題となるでしょう。特に、仮想化等でリソース配分を動的に最適化しているDC等のクラウド系のサーバビジネスあたりには致命的なインパクトがある筈です。脆弱性を放置する選択肢は取り得ませんから、パッチを当てた瞬間不足に陥るべき数割のリソースを事前に増強する必要があるわけですが、当然ながらそのコストは大変な事になるのですし、Amazon、Google、Microsoftはじめ、各社とも今頃は大変な騒ぎになっていることでしょう。というか私も管理してるサーバのリソース見直しとか頭が痛い。。。どうしよう。
ユーザが対処に追われる一方、当の犯人たるIntelは、まだ何もアクションを起こしていません。生じた被害はここ十年に販売したCPU全部すなわち数億件レベルで言うまでもなく甚大、Intel側で修正は不可能なために被害を食い止める事も出来ず、そもそも現行製品も対象でアーキテクチャの根本的な見直しが必要になる以上、問題を認めた瞬間に全製品が販売停止から回収となり、かつソフト側の対処に伴う費用とそれで落ちる性能分の損害賠償or増強費用を合算した空前の規模の損害賠償責任が降りかかってくるわけで、そりゃちょっとどうしていいかわからなくなるのも無理はないとも思いますけれども。しかしだからといってだんまりを決め込んでもどうにもならないでしょうし、潔く腹を切るしかないのではないかと思うのですが、さてどうしてくれるんでしょう。
なお、Intel以外のCPUではどうかというと、AMDは問題ない旨リリースを出していますが、ARMは何か怪しいです。というのも、ARM向けにも同様のパッチが準備されている、という話が出ているからです。ARMも、となると、スマホやタブレット、各種IoTデバイス等、一気に対象が広がってしまい、只でさえ大変な本件の規模がさらに何倍、という惨事になってしまうわけですが。。。どうなってしまうんでしょう。というか、そうだとしたら、どうにかなるのかこれ？
先日のファームウェアの脆弱性についてもまだ解決されていないのに。。。私のところのサーバに使っているJ3455M-Eの対策済みBIOSはまだリリースの予定すら立っていないようです。こっちも同じ位洒落になりません。まあこっちはマザーボードメーカー（ASUS）の問題ではあるのですけど。
The mysterious case of the Linux Page Table Isolation patches
で、あっという間に横展開の調査も進み、本件に加えてさらに同種の脆弱性も発覚してしまいました。しかもこちらはARMやAMDのチップも対象に含まれています。
[続き記事 [PC] Meltdownに続き、Spectre脆弱性発覚でCPU全陣営が一斉崩壊の危機]
[関連記事 [PC] 現行Intel製チップのファームウェアの大半に脆弱性発覚]
Subscribe to:
Posts (Atom)
Posts
