停滞ないし凋落の激しい電機業界にあって、負け組に分類されて久しく、ジリ貧ながらもリストラを繰り返す事で致命的な損失は回避し、しぶとく生き残って来たNECが、来年度にまたしても3000人をリストラするんだそうです。
対象は国内で、通信機器等のハードウェア部門及び間接部門。ハードはともかく、間接部門なんて過去のリストラで削りに削って来た筈で、今更そんなに余剰があるのか、いささか疑問を感じないではないですが、計画ではそうなっているとのこと。
そして、今後注力する分野は、お決まりのSI関連です。プロダクトが不採算に陥った電機メーカーが、ITサービス関連に注力する、というのは判を押したように何処も大体同じなわけですが、それだけだとジリ貧、という事で他社との差別化のために挙げられたのが顔認証です。海外の防犯向けを拡販して主力に育てるつもりだとか。
しかし、顔認証を含むNECのセキュリティ関連事業の売上高は年400億程度、NECの売上高の2%にも届いていないのです。これを主力に育てる、というのは、数年の内に少なくとも数倍以上に成長する、と言っているに等しいわけですが、特に最近特別な新製品が生まれたわけでもないのに、これからそんな急成長する、と言われても、率直に言って現実性に乏しいものと言わざるを得ません。
そもそも、これまでの市場や社会の動向から見て、顔認証にそこまでのニーズがあるかどうかも明らかではないわけで。というか、顔認証の導入で何らかの成功を得た例というのが殆どないのですね。失敗とか無駄に終わったとかいう話なら山程あるのですが。
実際、過去様々なところで行われた監視カメラ等による指名手配犯検挙等のサーベイランスの実験も、成功したという話は皆無でもありますし、国内空港への導入に際しても、実験で散々な結果が出て一度は頓挫したのを、多分に政治的に無理やり復活させてねじ込んだという有り様です。一部アミューズメントパーク等のゲートでの認証に採用されてはいますが、そのようなゲートを、莫大なコストをかけてまで導入する事が、必然的もしくはそこまでいかずとも自然と言えるようなシチューションが果たしてそんなにあるものか、疑問を抱かずにはいられないのです。
結局のところ、訴求するために必要な類の実績が全く足りていない、というか殆ど皆無なのが問題なのであって、それを解決しない事には成長も何もあったものではない、のではないかと。
もっとも、その辺の非情な現実は当のNEC自身が一番良く承知している筈ですし、自分でもそんな夢物語は信じておらず、リストラをするにあたり、夢も希望もなくただ削減、という形になる事を回避するため、体裁を取り繕う建前を探したところ、顔認証位しか使えるものが無かった、というだけの事なのかもしれませんけれども。
だとしたら、一番大変なのは、具体的な見通しも何も無いままに、社全体の未来を背負う、そんな無茶な目標を押し付けられる羽目になるだろう顔認証部門の開発・営業の担当者たちなのかもしれませんね。どうしろっていうんだよ、というところでしょうか。といって、それらの部門は、長い間、近い将来はこう成長する、こんな可能性がある、と色々な建前を掲げ、それで少なくない運転資金や利益を得て来ている筈で、その山のように積み上がったコミットメントを果たす責任はあるわけです。そうである以上、無謀だとしても今更放棄や撤退は許されない、それは仕方ないところではあるのでしょう。
ただ、その辺は全てNECの内部の事情に過ぎません。必要性もメリットもない顧客に押し売りするような真似だけはしないで頂きたいものです。無論、必要性とメリットが十分にあり、かつデメリットが許容可能であり、コストとも釣り合う、というのを顧客がよく理解し納得して、勿論メーカー側から性能や精度その他ごまかしや隠蔽が無い、というのであれば何も問題はないのですが。
NEC、来年度にも国内3千人削減へ 海外展開に出遅れ
[関連記事 [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製チップのファームウェアの大半に脆弱性発覚]
12/24/2017
[note] Ubuntu17.10、BIOS破壊バグで丸ごと取り下げ、ユーザは放置。Ubuntuは終わるか
いつの間にか公開中止になってるんですね。Ubuntuの最新版であるところの17.10が。
理由はバグ。カーネル中のintel-spi-*ドライバの不具合により、Lenovo製を中心に複数のPCでBIOSを変更不能にしてしまうという酷いもので、USB等のレスキュー用のブートデバイスが使用不能になって復旧も出来なくなってしまうケースが生じているんだそうです。spiドライバはBIOSの操作に用いられるシリアルインタフェース用のドライバです。通常、OS側からBIOSの書き換えは行わないし、その必要もない筈なのに、何故こんな事が起こるのか、俄には信じ難い話です。しかし起こってしまったものは仕方ありません。
本件バグの影響を受ける事が確認された機種は、LenovoのYogaシリーズ、B,G,Yの各機種を含む多数機種、またAcerのTravelMateや東芝のSatelliteの複数モデルでも発生の旨報告が上がっています。当該機種でUbuntuを導入しているユーザは相当多数いた事は間違いありません。従って被害も甚大なものになってしまいました。
本件不具合は、11月の下旬にレポートが上がり、Ubuntuユーザを恐怖と絶望のどん底に突き落としました。既に17.10にアップグレード済みだった私も例に漏れず、慌てて確認しましたが、セーフで胸を撫で下ろしたのです。LenovoのPCも複数含まれていましたが、旧機種だった事が幸いしたようです。
リリース当初から多数の深刻な不具合を抱え、とても人には勧められないものである事は明らかだった17.10ですが、それらによって適用を見送った、もしくは様子見する事にしたユーザも多いでしょうけれども、結果としてそれが大正解であった、という事になります。
これだけの致命的とも言うべき被害が出てしまうと、通常ならば誰かがそれなりに責任を負わなければ収まらない話なんでしょうけれども、どうも誰も責任を取らない流れになりそうで、誠に遺憾な限りです。
まず、本件バグの影響が複数メーカーに及んでいる点からして、LenovoらのBIOS側がしばしば独自に導入するところの排他的な仕様に起因するものという事も出来ず、本件の責任は専らBIOSにライトアクセスをするモジュールを軽率に導入したCanonical側にあるものと言う他無いでしょう。ブートすら出来なくなり、かつ未だに復旧出来ていないユーザもいるようで、損害賠償等を請求されても当然な状況です。
しかし、Ubuntuの公式HP上では、本件について少なくともトップ近辺では何も触れられておらず、かろうじてダウンロードページの通常ダウンロードボタンがある筈の隅に公開停止中の旨が記載されているのと、Ubuntu17.10のリリースノート中に同様の、半端な記載があるだけです。あくまで自己責任として、一切の責任は取らない、どころか通常の脆弱性等と同程度のよくある問題として扱い、何もなかったものとするつもり、としか受け取りようがありません。
で、ダウンロードページでは、17.10など無かったかのように16.04LTSのダウンロードのみを掲げ、17.10のリリースノート中でも16.04LTSを使用するように促されているわけですが。。。寝言は寝て言えというのです。ロールバックの手段もないし、そもそもライブラリ等のパッケージ構成も異なるのに、そんな事出来るわけがないのですから。要するに、ユーザは自力で再インストールするなりして解決しろ、というわけです。
OSSであり、無料のソフトである以上、その選択も法的には原則として問題ないのでしょう。また、責任を取ろうにも、その能力、資力がない、という事情もあるのかもしれません。ですけれども、少なくともユーザのPCを使用不能に陥らせる危険があり、発生すればその復旧すら困難になるような致命的な問題を漫然と看過して正式リリースし、実際に甚大な被害を生じさせておきながら、それを認識した後もその被害の拡大防止を図ることすらせず、ただこそこそとHPからリリースを取り下げるだけで、その問題の告知も謝罪もない、さらにはロールバック等の復旧手段の提供もない、というのは、既存と潜在とを問わず、ユーザに容認され得るものでは到底ないように思われるところです。
長年ユーザを続けている私ですら、本件で認識させられたCanonicalの体制、姿勢に起因するだろうリスクは看過し難いものと感じ、他のディストリビューションへの切替えを真剣に考慮している程なのです。既にUbuntuを見限った向きも少なくはないのではないでしょうか。本件の経緯からすれば、もはや残念とも感じず、当然としか思いませんが、寂しい限りですね。
Canonicalのやり方を見る限り、今後再発する危険性は高いものと考えざるを得ず、だとするとLTSなら大丈夫、とかいう話でもないように見えますし、Ubuntuはもう駄目かもしれないと言わざるを得ません。一応本件バグの対象はDesktopのみで、Serverは対象外につき取り下げもされていないようですが、まとめて信用ガタ落ちは必至です。早めにCentOSに乗り換えた方がいいかもしれません。しかし、またそれ用に設定するの?また面倒な。。。とほほ。
Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models
[過去記事 [note] ubuntu17.10は不具合多数、回避or様子見推奨]
理由はバグ。カーネル中のintel-spi-*ドライバの不具合により、Lenovo製を中心に複数のPCでBIOSを変更不能にしてしまうという酷いもので、USB等のレスキュー用のブートデバイスが使用不能になって復旧も出来なくなってしまうケースが生じているんだそうです。spiドライバはBIOSの操作に用いられるシリアルインタフェース用のドライバです。通常、OS側からBIOSの書き換えは行わないし、その必要もない筈なのに、何故こんな事が起こるのか、俄には信じ難い話です。しかし起こってしまったものは仕方ありません。
本件バグの影響を受ける事が確認された機種は、LenovoのYogaシリーズ、B,G,Yの各機種を含む多数機種、またAcerのTravelMateや東芝のSatelliteの複数モデルでも発生の旨報告が上がっています。当該機種でUbuntuを導入しているユーザは相当多数いた事は間違いありません。従って被害も甚大なものになってしまいました。
本件不具合は、11月の下旬にレポートが上がり、Ubuntuユーザを恐怖と絶望のどん底に突き落としました。既に17.10にアップグレード済みだった私も例に漏れず、慌てて確認しましたが、セーフで胸を撫で下ろしたのです。LenovoのPCも複数含まれていましたが、旧機種だった事が幸いしたようです。
リリース当初から多数の深刻な不具合を抱え、とても人には勧められないものである事は明らかだった17.10ですが、それらによって適用を見送った、もしくは様子見する事にしたユーザも多いでしょうけれども、結果としてそれが大正解であった、という事になります。
これだけの致命的とも言うべき被害が出てしまうと、通常ならば誰かがそれなりに責任を負わなければ収まらない話なんでしょうけれども、どうも誰も責任を取らない流れになりそうで、誠に遺憾な限りです。
まず、本件バグの影響が複数メーカーに及んでいる点からして、LenovoらのBIOS側がしばしば独自に導入するところの排他的な仕様に起因するものという事も出来ず、本件の責任は専らBIOSにライトアクセスをするモジュールを軽率に導入したCanonical側にあるものと言う他無いでしょう。ブートすら出来なくなり、かつ未だに復旧出来ていないユーザもいるようで、損害賠償等を請求されても当然な状況です。
しかし、Ubuntuの公式HP上では、本件について少なくともトップ近辺では何も触れられておらず、かろうじてダウンロードページの通常ダウンロードボタンがある筈の隅に公開停止中の旨が記載されているのと、Ubuntu17.10のリリースノート中に同様の、半端な記載があるだけです。あくまで自己責任として、一切の責任は取らない、どころか通常の脆弱性等と同程度のよくある問題として扱い、何もなかったものとするつもり、としか受け取りようがありません。
で、ダウンロードページでは、17.10など無かったかのように16.04LTSのダウンロードのみを掲げ、17.10のリリースノート中でも16.04LTSを使用するように促されているわけですが。。。寝言は寝て言えというのです。ロールバックの手段もないし、そもそもライブラリ等のパッケージ構成も異なるのに、そんな事出来るわけがないのですから。要するに、ユーザは自力で再インストールするなりして解決しろ、というわけです。
OSSであり、無料のソフトである以上、その選択も法的には原則として問題ないのでしょう。また、責任を取ろうにも、その能力、資力がない、という事情もあるのかもしれません。ですけれども、少なくともユーザのPCを使用不能に陥らせる危険があり、発生すればその復旧すら困難になるような致命的な問題を漫然と看過して正式リリースし、実際に甚大な被害を生じさせておきながら、それを認識した後もその被害の拡大防止を図ることすらせず、ただこそこそとHPからリリースを取り下げるだけで、その問題の告知も謝罪もない、さらにはロールバック等の復旧手段の提供もない、というのは、既存と潜在とを問わず、ユーザに容認され得るものでは到底ないように思われるところです。
長年ユーザを続けている私ですら、本件で認識させられたCanonicalの体制、姿勢に起因するだろうリスクは看過し難いものと感じ、他のディストリビューションへの切替えを真剣に考慮している程なのです。既にUbuntuを見限った向きも少なくはないのではないでしょうか。本件の経緯からすれば、もはや残念とも感じず、当然としか思いませんが、寂しい限りですね。
Canonicalのやり方を見る限り、今後再発する危険性は高いものと考えざるを得ず、だとするとLTSなら大丈夫、とかいう話でもないように見えますし、Ubuntuはもう駄目かもしれないと言わざるを得ません。一応本件バグの対象はDesktopのみで、Serverは対象外につき取り下げもされていないようですが、まとめて信用ガタ落ちは必至です。早めにCentOSに乗り換えた方がいいかもしれません。しかし、またそれ用に設定するの?また面倒な。。。とほほ。
Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models
[過去記事 [note] ubuntu17.10は不具合多数、回避or様子見推奨]
12/19/2017
[biz law] 中央リニア受注業者が談合で全滅、工事の行方は
JRの中央リニア工事の談合疑惑の件、結局のところ、受注に参加した大手ゼネコンは全滅必至な感じですか。。。
無論、本件はまだ捜査中の段階であり、今まさに押収され、これから行われる資料の精査や、これから本格化するだろう関係者の聴取から証拠が出ない限りは確定ではないのですけれども。しかし、本プロジェクトの規模、期間等の重要性の高さと、是が非でも受注を逃したくはなかっただろう各社の事情等から、受注とその価格についての不正、有り体に言えば談合が行われる可能性は元々強く疑われていました。その主たる根拠であるところの建設業界の談合体質、その山のように積み上げられた前科については言うまでもありません。
そこに、検察当局による本件の摘発が開始されてから追加された情報、殊にJR東海の担当社員による価格漏洩の是認を筆頭として疑惑を裏付ける性質の当事者の証言が相次ぎ、一方で否定する性質のものは殆ど皆無です。一応、当該容疑のかかっている各社の経営陣は今の所疑惑を否認しているようですが、特に根拠もなく、単にやっていない、と言うばかりのもので、ほぼ無意味と言っていいでしょう。この状況を見て、黒だと思わない者がいるでしょうか。
まだ捜査が始まったばかりの状態でこれです。押収された資料の精査や、おそらくは受注企業の殆どに及ぶだろう聴取等の捜査が進めば、どれだけの容疑が出てくるか、第3者の立場から想像するだけでも冷や汗が出る気がします。うっかり別件が発覚する可能性も高いでしょうし。
とはいえ、犯罪は犯罪、それも故意が明らかな、極めて悪質なものです。いくら当人たちが必要悪だとか強弁しようとも、事が露見した以上は相応の刑罰に服する他ありません。皆それは十二分に承知の上での犯行なのでしょうし、それは今更どうこう言い得るものではないのです。何人たりとも。
ただ、工事の方はどうなるんでしょう。周知の通り、中核たるトンネル掘削等の路線敷設関連の工事はその必要となるノウハウを持つ業者が極めて少なく、今回摘発されている業者以外に担えるところはないと言われています。それが摘発され、仮に工事から除外された場合、当然ながら工事自体が立ち行きません。さりとてこのまま担当を変更せずに工事を進める、というのも談合を追認するに等しく、司法当局としても容認し得るものではないでしょう。
これが、工事が相当に進んだ後に発覚したのであれば、やむを得ず工事の担当の継続を認めるという事になったのかもしれませんが、幸いにしてまだ殆どの工事が始まったばかりで、中止の選択肢も残されています。また、トンネル部分はさておき、今回端緒となった大林組の名古屋の出口工事を含め、他の業者にも施工可能につき、入れ替えが可能な部分も多々あります。全て替えが効かない、という事は有り得ません。であれば、入れ替え可能な部分を選別し、それについては談合組排除の上で再入札等を行い、入れ替え不能な部分については別途ペナルティを与えた上で継続、等の複雑な措置を採る必要があるものと考えられます。しかし、 それは言うまでもなく大変な事です。色んな意味で。
本件を受けて、これからどうするのか、どう始末を付けるのか。中央リニアプロジェクト自体の帰趨をも左右するだろうその後始末は、多数の選択肢が残されているだけに厄介です。存在するのかどうかも不明ですが、もし本件談合に参加出来ず、しかし部分的にでも工事を担えるだけの能力を持つ陣営があるのであれば、これ幸いと食い込み、というより奪い取りにかかるでしょう。一方談合組は、一定の責任追及は甘受しつつも、受注自体は維持しようと画策する筈です。これまで関与が制限、というより原則排除されてきた格好の自治体や政府が好機と見て介入する事もあり得るでしょう。
ただでさえ膨大な利害が絡み合うプロジェクトです。果たして元々の計画の維持は出来るのか。少なくとも工期の延長は必至だと思われますが、むしろそれで済むのか、適当なところに落ち着ける事が出来るのか、それすらも危ういように見えます。下手をすればこのまま頓挫しかねない勢いですが、もしそうなれば、それは工事そのものの困難さによるのではなく、欲をかいた関係者の違法行為によって、という事になるわけです。いや大変な事になりました。どうなっちゃうんでしょうね。中央リニア事業については個人的にも期待していただけに、このような事になってしまった事は極めて残念に思います。
何にせよ、本件談合をやらかした大手ゼネコン連中には、相応の報いを受けて頂かなくてはなりません。検察には、容赦のない、徹底的な追及を期待したいですね。検察は不祥事以来のここ数年、何もしていなかったに等しいのですし、その分働いてもらわなくては。
[関連記事 [biz] 中央リニア建設批判、その周囲に漂う無責任]
無論、本件はまだ捜査中の段階であり、今まさに押収され、これから行われる資料の精査や、これから本格化するだろう関係者の聴取から証拠が出ない限りは確定ではないのですけれども。しかし、本プロジェクトの規模、期間等の重要性の高さと、是が非でも受注を逃したくはなかっただろう各社の事情等から、受注とその価格についての不正、有り体に言えば談合が行われる可能性は元々強く疑われていました。その主たる根拠であるところの建設業界の談合体質、その山のように積み上げられた前科については言うまでもありません。
そこに、検察当局による本件の摘発が開始されてから追加された情報、殊にJR東海の担当社員による価格漏洩の是認を筆頭として疑惑を裏付ける性質の当事者の証言が相次ぎ、一方で否定する性質のものは殆ど皆無です。一応、当該容疑のかかっている各社の経営陣は今の所疑惑を否認しているようですが、特に根拠もなく、単にやっていない、と言うばかりのもので、ほぼ無意味と言っていいでしょう。この状況を見て、黒だと思わない者がいるでしょうか。
まだ捜査が始まったばかりの状態でこれです。押収された資料の精査や、おそらくは受注企業の殆どに及ぶだろう聴取等の捜査が進めば、どれだけの容疑が出てくるか、第3者の立場から想像するだけでも冷や汗が出る気がします。うっかり別件が発覚する可能性も高いでしょうし。
とはいえ、犯罪は犯罪、それも故意が明らかな、極めて悪質なものです。いくら当人たちが必要悪だとか強弁しようとも、事が露見した以上は相応の刑罰に服する他ありません。皆それは十二分に承知の上での犯行なのでしょうし、それは今更どうこう言い得るものではないのです。何人たりとも。
ただ、工事の方はどうなるんでしょう。周知の通り、中核たるトンネル掘削等の路線敷設関連の工事はその必要となるノウハウを持つ業者が極めて少なく、今回摘発されている業者以外に担えるところはないと言われています。それが摘発され、仮に工事から除外された場合、当然ながら工事自体が立ち行きません。さりとてこのまま担当を変更せずに工事を進める、というのも談合を追認するに等しく、司法当局としても容認し得るものではないでしょう。
これが、工事が相当に進んだ後に発覚したのであれば、やむを得ず工事の担当の継続を認めるという事になったのかもしれませんが、幸いにしてまだ殆どの工事が始まったばかりで、中止の選択肢も残されています。また、トンネル部分はさておき、今回端緒となった大林組の名古屋の出口工事を含め、他の業者にも施工可能につき、入れ替えが可能な部分も多々あります。全て替えが効かない、という事は有り得ません。であれば、入れ替え可能な部分を選別し、それについては談合組排除の上で再入札等を行い、入れ替え不能な部分については別途ペナルティを与えた上で継続、等の複雑な措置を採る必要があるものと考えられます。しかし、 それは言うまでもなく大変な事です。色んな意味で。
本件を受けて、これからどうするのか、どう始末を付けるのか。中央リニアプロジェクト自体の帰趨をも左右するだろうその後始末は、多数の選択肢が残されているだけに厄介です。存在するのかどうかも不明ですが、もし本件談合に参加出来ず、しかし部分的にでも工事を担えるだけの能力を持つ陣営があるのであれば、これ幸いと食い込み、というより奪い取りにかかるでしょう。一方談合組は、一定の責任追及は甘受しつつも、受注自体は維持しようと画策する筈です。これまで関与が制限、というより原則排除されてきた格好の自治体や政府が好機と見て介入する事もあり得るでしょう。
ただでさえ膨大な利害が絡み合うプロジェクトです。果たして元々の計画の維持は出来るのか。少なくとも工期の延長は必至だと思われますが、むしろそれで済むのか、適当なところに落ち着ける事が出来るのか、それすらも危ういように見えます。下手をすればこのまま頓挫しかねない勢いですが、もしそうなれば、それは工事そのものの困難さによるのではなく、欲をかいた関係者の違法行為によって、という事になるわけです。いや大変な事になりました。どうなっちゃうんでしょうね。中央リニア事業については個人的にも期待していただけに、このような事になってしまった事は極めて残念に思います。
何にせよ、本件談合をやらかした大手ゼネコン連中には、相応の報いを受けて頂かなくてはなりません。検察には、容赦のない、徹底的な追及を期待したいですね。検察は不祥事以来のここ数年、何もしていなかったに等しいのですし、その分働いてもらわなくては。
[関連記事 [biz] 中央リニア建設批判、その周囲に漂う無責任]
12/08/2017
[biz] GEも電力部門リストラ12000人
先日の独ジーメンスに続き、米GEもタービン等の発電用機器を製造販売する電力部門で大規模なリストラをする運びになったそうです。
理由も同じ。再生エネルギーへの移行等により火力発電はじめ従来型の発電機器の需要が減少し、生産能力が過剰になったため。アメリカで再生エネルギーと言うと太陽光発電・・・が当初の掛け声からすると微妙な感じというか殆ど頓挫したような状態ではありますが、TESLA等がまだ一応諦めていない状態で、少なくとも当分の間は大幅な回帰はないだろうとGEも判断したという事なのでしょう。独Siemensの件と併せて考えれば、競争云々より市場全体が供給過多になっているものと解すべきでしょうか。
ただ、再生エネもその喧伝ぶりに反して、規模的には従来型の電力ソースを置き換え得るレベルには全く達していないわけで。にも関わらずこの規模のリストラをするというのは、ジーメンスにしろGEにしろ、基本的に電力需要は全体で見てもあまり伸びないものと考えている、と解釈すべきところなのでしょう。そして、両社とも、その顧客すなわち電力会社の意向、動向等を含め、市場の状況は十二分に把握しているだろうし、それを踏まえての施策なのでしょうから、これは電力業界の大方の見方と理解して差し支えないものと思われます。
という事は、電力の供給側は、EV等の新規に大規模な電力ソースを必要とする類の機器についても、自動車メーカー等の動向に関わらず、さほど普及しないものと考えている、という事になるわけですが。。。無情というか何と言うか。今まさに躓く、というより盛大にすっ転んで頭を打ち、下手をすればそのまま死にかねない感じのTESLAにしてみれば、死んだものと考えた親族が葬式の準備を始めた感じでしょうか。この状況からの復帰は容易ではないでしょうけれど、さてどうなる事やら。
GE Plans 12,000 Job Cuts as New CEO Revamps Power Unit
[関連記事 [biz] 独Siemens、電力関連6900人リストラ]
理由も同じ。再生エネルギーへの移行等により火力発電はじめ従来型の発電機器の需要が減少し、生産能力が過剰になったため。アメリカで再生エネルギーと言うと太陽光発電・・・が当初の掛け声からすると微妙な感じというか殆ど頓挫したような状態ではありますが、TESLA等がまだ一応諦めていない状態で、少なくとも当分の間は大幅な回帰はないだろうとGEも判断したという事なのでしょう。独Siemensの件と併せて考えれば、競争云々より市場全体が供給過多になっているものと解すべきでしょうか。
ただ、再生エネもその喧伝ぶりに反して、規模的には従来型の電力ソースを置き換え得るレベルには全く達していないわけで。にも関わらずこの規模のリストラをするというのは、ジーメンスにしろGEにしろ、基本的に電力需要は全体で見てもあまり伸びないものと考えている、と解釈すべきところなのでしょう。そして、両社とも、その顧客すなわち電力会社の意向、動向等を含め、市場の状況は十二分に把握しているだろうし、それを踏まえての施策なのでしょうから、これは電力業界の大方の見方と理解して差し支えないものと思われます。
という事は、電力の供給側は、EV等の新規に大規模な電力ソースを必要とする類の機器についても、自動車メーカー等の動向に関わらず、さほど普及しないものと考えている、という事になるわけですが。。。無情というか何と言うか。今まさに躓く、というより盛大にすっ転んで頭を打ち、下手をすればそのまま死にかねない感じのTESLAにしてみれば、死んだものと考えた親族が葬式の準備を始めた感じでしょうか。この状況からの復帰は容易ではないでしょうけれど、さてどうなる事やら。
GE Plans 12,000 Job Cuts as New CEO Revamps Power Unit
[関連記事 [biz] 独Siemens、電力関連6900人リストラ]
12/07/2017
[biz law] VW米法人役員に禁錮7年の実刑
が言い渡されたそうです。加えて40万ドルの罰金。重いのか軽いのか判断しづらいですね。日本基準で言えば非常に重いと言えるでしょうが、米国基準なら軽いと言うべきでしょうか。一応、法定刑の上限だそうですが、何せ規模、悪質さ共に前代未聞でしたから、法が予定していなかったレベルの罪を既存の範囲内で最大限裁いた結果という事なのでしょう。
容疑者はOliver Schmidt、同社米法人のMichigan州の担当役員でした。容疑は言うまでもなくDieselgateの米国内での案件全般、すなわち米国向け同社製ディーゼル車につき米規制当局の排気ガス検査時にのみ動作し、通常走行時には動作しない排ガス低減装置・機能を搭載する事で検査を欺き、違反車両数十万台を米国内で販売して法令に違反した罪という事になります。
容疑者は逮捕後は容疑を認めており、4年以下の懲役と10万ドル以下の罰金への量刑の軽減を求めていましたが、通りませんでした。
有罪との判断、及び量刑については、その悪質さと規模、また同氏が独VWの子会社内とはいえ上級の役員であり、米当局に対し繰り返し虚偽を述べていた事等から、特に疑義を挟む向きもないようです。ただ、本件は元々本国ドイツのVW本社で計画され、そのBoschが担当したとされる装置や制御ソフト等の開発も同じくドイツで行われたもので、米国法人はそれらを米国で販売するにあたっての当局への窓口に過ぎませんでした。そして、現時点ではその主犯たる独VW本社の面々は訴追も聴取もされていないわけです。そうである以上、Schmidt氏が断罪されたからといって、本件でなされるべき責任追及は一段落したとすら言えないだろう事は明らかです。
しかし、独の面々はその政治力によって守られ、米国へのその身柄の引き渡しはおろか、ドイツ国内で訴追される見込みもありません。クリーンディーゼル自体を無かった事にするかのように、EV事業のアピールに邁進する一方で、その指示に従った米国法人の役員は長期に渡る収監を余儀なくされるわけです。Schmidt氏に同情する余地はありませんが、同氏が公判内で訴えたとされる、その本社の決定に従ったに過ぎないのだ、との弁解、またその裏にあるだろう心情には、氏自身の罪の内には収まらない理不尽と不公平を見出さざるを得ません。
Schmidt氏が本件訴追に至った経緯についても、ドイツ国籍を有し、国内に留まっていればその他の役員らと同様に逮捕されなかっただろう同氏が、"たまたま"Floridaへ旅行に訪れた際に米当局に逮捕された、というのです。その不自然さから、同氏をスケープゴートにしようとしたという類の本社の思惑を疑う向きもある程です。
同氏が逮捕された時は、これで芋づる式にVW本社周りにも追及がなされるものだと期待したのですが、結果は完全に逆、全く進んでいません。同社以外にも偽装が発覚した伊・仏の大手各社も同様で、訴追以前にまともに捜査さえも行われていない現状、それが示すEU周辺の政財界の想像を絶する腐敗ぶりに、愕然とせざるを得ないのです。どうにもならないのでしょうか。
ところで、本件で吹っ飛んだクリーンディーゼルの代わりとしてVWが注力しているEV事業は、同社の掛け声の強さにも関わらず、今の所全く売れる気配もなく、同社の思うようには全く進んでいません。おそらく同社に怨恨を募らせているだろう同氏には、それが小さくない慰めになっているのかもしれませんね。それで足りる筈もないのでしょうけれど。
Volkswagen Official Gets 7-Year Term in Diesel-Emissions Cheating
[関連記事 [biz law] VW米法人の規制対応部門責任者逮捕]
[過去記事 [biz law] VWディーゼル車に排気ガス適合試験での不正プログラム使用発覚]
容疑者はOliver Schmidt、同社米法人のMichigan州の担当役員でした。容疑は言うまでもなくDieselgateの米国内での案件全般、すなわち米国向け同社製ディーゼル車につき米規制当局の排気ガス検査時にのみ動作し、通常走行時には動作しない排ガス低減装置・機能を搭載する事で検査を欺き、違反車両数十万台を米国内で販売して法令に違反した罪という事になります。
容疑者は逮捕後は容疑を認めており、4年以下の懲役と10万ドル以下の罰金への量刑の軽減を求めていましたが、通りませんでした。
有罪との判断、及び量刑については、その悪質さと規模、また同氏が独VWの子会社内とはいえ上級の役員であり、米当局に対し繰り返し虚偽を述べていた事等から、特に疑義を挟む向きもないようです。ただ、本件は元々本国ドイツのVW本社で計画され、そのBoschが担当したとされる装置や制御ソフト等の開発も同じくドイツで行われたもので、米国法人はそれらを米国で販売するにあたっての当局への窓口に過ぎませんでした。そして、現時点ではその主犯たる独VW本社の面々は訴追も聴取もされていないわけです。そうである以上、Schmidt氏が断罪されたからといって、本件でなされるべき責任追及は一段落したとすら言えないだろう事は明らかです。
しかし、独の面々はその政治力によって守られ、米国へのその身柄の引き渡しはおろか、ドイツ国内で訴追される見込みもありません。クリーンディーゼル自体を無かった事にするかのように、EV事業のアピールに邁進する一方で、その指示に従った米国法人の役員は長期に渡る収監を余儀なくされるわけです。Schmidt氏に同情する余地はありませんが、同氏が公判内で訴えたとされる、その本社の決定に従ったに過ぎないのだ、との弁解、またその裏にあるだろう心情には、氏自身の罪の内には収まらない理不尽と不公平を見出さざるを得ません。
Schmidt氏が本件訴追に至った経緯についても、ドイツ国籍を有し、国内に留まっていればその他の役員らと同様に逮捕されなかっただろう同氏が、"たまたま"Floridaへ旅行に訪れた際に米当局に逮捕された、というのです。その不自然さから、同氏をスケープゴートにしようとしたという類の本社の思惑を疑う向きもある程です。
同氏が逮捕された時は、これで芋づる式にVW本社周りにも追及がなされるものだと期待したのですが、結果は完全に逆、全く進んでいません。同社以外にも偽装が発覚した伊・仏の大手各社も同様で、訴追以前にまともに捜査さえも行われていない現状、それが示すEU周辺の政財界の想像を絶する腐敗ぶりに、愕然とせざるを得ないのです。どうにもならないのでしょうか。
ところで、本件で吹っ飛んだクリーンディーゼルの代わりとしてVWが注力しているEV事業は、同社の掛け声の強さにも関わらず、今の所全く売れる気配もなく、同社の思うようには全く進んでいません。おそらく同社に怨恨を募らせているだろう同氏には、それが小さくない慰めになっているのかもしれませんね。それで足りる筈もないのでしょうけれど。
Volkswagen Official Gets 7-Year Term in Diesel-Emissions Cheating
[関連記事 [biz law] VW米法人の規制対応部門責任者逮捕]
[過去記事 [biz law] VWディーゼル車に排気ガス適合試験での不正プログラム使用発覚]
12/04/2017
[biz] FREETEL破綻
安価帯のSIMフリー端末関連事業の(比較的)大手、FREETELのプラスワン・マーケティングが民事再生手続を申請して破綻したんだそうです。
と言っても、債務総額は26億、債権者数も100強に過ぎず、知名度の割にその規模は大きいものとは言えませんし、本件自体はさほど騒ぐ程のものではないのでしょう。
本件破綻について、同社が運営していたMVNO事業とそれ向けのSIMフリー端末事業とを切り離して論じる意味はあまりないのかもしれませんが、まずFREETELブランドのMVNO事業は既に譲渡済みにつき、本件倒産は回線契約ユーザには影響しません。また、端末のユーザについても、同社の端末は大半が一般の小売業者からの買い切りでしょうから、保証・修理等のアフターサポートを受けられなくなる以上の不利益は殆どないでしょう。サポートが無くなる点にしたところで、もともとこの種の端末はそれらを必要としない層が中心で、かつ1万〜2万前後の安価な端末につき、使い捨てと割り切って気にしないユーザも多いだろうと推測されます。これらの点を鑑みても、実質的に見てさほど大きな問題にはならないのではないでしょうか。なんかCoinとかポイント的なものも発行していたようですが、その規模も推して知るべしですし、特に考慮すべきものでもないでしょう。
むしろ、プラスワン社周り以上に、本件でユーザからの問い合わせ等が殺到するだろう、FREETELブランドのMVNO事業を引き継いだ楽天の方が面倒な事になりそうです。まあ、名義を続用している以上、法的に言ってもその辺は予想された範囲内の責任につき仕方のないところと諦めてもらう他ないのでしょうけれども。
数多あるMVNO事業者や端末メーカーの中で、同社が破綻に至った原因は、概ね明らかです。要するに事業計画が甘く、広告や出店に予想される収益に不釣り合いな巨額の資金を投じたため、採算が取れなくなって破綻したというだけの事です。
というか、あの強気さ加減は、率直に言って意味不明でした。資本力、ブランド、ノウハウ等、およそあらゆる面で競合他社に対して特別優位にあったわけでもなく、むしろ体力面ではIIJは無論として大手系列の事業者には著しく劣っていたわけで。また、同社が一応競合他社と差別化し得る強みと考えていただろう自社ブランドの端末にしても、安価ではあるものの、値段相応の価値しかないもので、とてもマジョリティーに訴求し得るようなものではありませんでした。保証等アフターで稼ごうにも、高額の保証料・修理代金等を、最安価帯のSIMフリー端末に支払うユーザなど殆どいません。何の根拠があって同社があれほどに強気な投資を行っていたのか、ちょっと理解し難く思われるところです。
果たしてその結果はご覧の通り。MVNO並びにそれ用の安価帯の端末の需要が急拡大する中ですらトントンないしは赤字であった同事業が、その市場全体の拡大フェーズが終了し、おそらくは同社の予想に反してiPhoneが過半のシェアを維持するに伴ってMVNOへの移行も滞る中、国内の限られたSIMフリー端末の買い替え・買い増しの需要をさらにHuawei、ASUS等大手を含む多数で取り合うとなれば、投資の回収など出来るわけもなく、破綻は必然であったと言う他ないでしょう。一応、破綻直前にMVNO事業を切り離して延命を試みはしたものの、その時点で既に採算が取れなくなっていた端末事業単体で業績を回復させ得る可能性がある筈もなし、単なる悪あがきに過ぎなかった事は明らかです。同社が事業計画を立てるにあたり、その基礎たる市場の動向の見通しをおそらくは根拠のない楽観論に立って見誤った時点で、既に詰んでいたという事なのでしょう。
ただ、これがMVNO周りのトレンドになるかというと、そうとも考えづらいところです。その他の業者の大半は、実店舗を持たず、広告も殆ど打たず、端末は外部調達のみであり、そもそも自前の投資自体殆ど行っていません。加えて、大手関連業者との資本関係、またそれに基づく抱き合わせ販売等の協力関係を有するところも多々あります。これらの差異を考慮すれば、FREETELが破綻したからといって、他のMVNO業者が一気に淘汰される、というわけでは必ずしもないように思われるわけです。 かつて同様に多数の業者が乱立し、その後淘汰されたプロバイダ事業等と比較してもMVNO関連事業は規模・収益性共に高く、成長の余地もあるのですしね。
他の業者には、これを教訓に無謀な投資は控え、堅実・誠実な事業運営がなされるよう願いたいところです。過渡期の事業分野で淘汰がなされるのは致し方ない事とは言え、情報通信は既に社会に欠くべからざるインフラの一つなのですから。その点、MVNO事業を事前に他社に譲渡した判断は、ユーザへのサービス提供を途切れさせる事なく保護したものと言えるでしょうし、一定の評価に値すると言ってよいかも知れません。
「FREETEL」元運営会社、民事再生法申請 負債額26億円
と言っても、債務総額は26億、債権者数も100強に過ぎず、知名度の割にその規模は大きいものとは言えませんし、本件自体はさほど騒ぐ程のものではないのでしょう。
本件破綻について、同社が運営していたMVNO事業とそれ向けのSIMフリー端末事業とを切り離して論じる意味はあまりないのかもしれませんが、まずFREETELブランドのMVNO事業は既に譲渡済みにつき、本件倒産は回線契約ユーザには影響しません。また、端末のユーザについても、同社の端末は大半が一般の小売業者からの買い切りでしょうから、保証・修理等のアフターサポートを受けられなくなる以上の不利益は殆どないでしょう。サポートが無くなる点にしたところで、もともとこの種の端末はそれらを必要としない層が中心で、かつ1万〜2万前後の安価な端末につき、使い捨てと割り切って気にしないユーザも多いだろうと推測されます。これらの点を鑑みても、実質的に見てさほど大きな問題にはならないのではないでしょうか。なんかCoinとかポイント的なものも発行していたようですが、その規模も推して知るべしですし、特に考慮すべきものでもないでしょう。
むしろ、プラスワン社周り以上に、本件でユーザからの問い合わせ等が殺到するだろう、FREETELブランドのMVNO事業を引き継いだ楽天の方が面倒な事になりそうです。まあ、名義を続用している以上、法的に言ってもその辺は予想された範囲内の責任につき仕方のないところと諦めてもらう他ないのでしょうけれども。
数多あるMVNO事業者や端末メーカーの中で、同社が破綻に至った原因は、概ね明らかです。要するに事業計画が甘く、広告や出店に予想される収益に不釣り合いな巨額の資金を投じたため、採算が取れなくなって破綻したというだけの事です。
というか、あの強気さ加減は、率直に言って意味不明でした。資本力、ブランド、ノウハウ等、およそあらゆる面で競合他社に対して特別優位にあったわけでもなく、むしろ体力面ではIIJは無論として大手系列の事業者には著しく劣っていたわけで。また、同社が一応競合他社と差別化し得る強みと考えていただろう自社ブランドの端末にしても、安価ではあるものの、値段相応の価値しかないもので、とてもマジョリティーに訴求し得るようなものではありませんでした。保証等アフターで稼ごうにも、高額の保証料・修理代金等を、最安価帯のSIMフリー端末に支払うユーザなど殆どいません。何の根拠があって同社があれほどに強気な投資を行っていたのか、ちょっと理解し難く思われるところです。
果たしてその結果はご覧の通り。MVNO並びにそれ用の安価帯の端末の需要が急拡大する中ですらトントンないしは赤字であった同事業が、その市場全体の拡大フェーズが終了し、おそらくは同社の予想に反してiPhoneが過半のシェアを維持するに伴ってMVNOへの移行も滞る中、国内の限られたSIMフリー端末の買い替え・買い増しの需要をさらにHuawei、ASUS等大手を含む多数で取り合うとなれば、投資の回収など出来るわけもなく、破綻は必然であったと言う他ないでしょう。一応、破綻直前にMVNO事業を切り離して延命を試みはしたものの、その時点で既に採算が取れなくなっていた端末事業単体で業績を回復させ得る可能性がある筈もなし、単なる悪あがきに過ぎなかった事は明らかです。同社が事業計画を立てるにあたり、その基礎たる市場の動向の見通しをおそらくは根拠のない楽観論に立って見誤った時点で、既に詰んでいたという事なのでしょう。
ただ、これがMVNO周りのトレンドになるかというと、そうとも考えづらいところです。その他の業者の大半は、実店舗を持たず、広告も殆ど打たず、端末は外部調達のみであり、そもそも自前の投資自体殆ど行っていません。加えて、大手関連業者との資本関係、またそれに基づく抱き合わせ販売等の協力関係を有するところも多々あります。これらの差異を考慮すれば、FREETELが破綻したからといって、他のMVNO業者が一気に淘汰される、というわけでは必ずしもないように思われるわけです。 かつて同様に多数の業者が乱立し、その後淘汰されたプロバイダ事業等と比較してもMVNO関連事業は規模・収益性共に高く、成長の余地もあるのですしね。
他の業者には、これを教訓に無謀な投資は控え、堅実・誠実な事業運営がなされるよう願いたいところです。過渡期の事業分野で淘汰がなされるのは致し方ない事とは言え、情報通信は既に社会に欠くべからざるインフラの一つなのですから。その点、MVNO事業を事前に他社に譲渡した判断は、ユーザへのサービス提供を途切れさせる事なく保護したものと言えるでしょうし、一定の評価に値すると言ってよいかも知れません。
「FREETEL」元運営会社、民事再生法申請 負債額26億円
11/28/2017
[biz law] 東レも偽装、隠蔽を試みるも暴露
繊維系最大手の東レも偽装、しかもこの期に及んで隠蔽しようとし、しかし元社員に暴露されて露見という。三菱マテからの連想で、似たようなポジションのここもヤバいんじゃ?と怪しんでいた向きもあったでしょうけど、それが正解であった事が最悪の形で明らかになってしまいました。材料・部品系は総崩れですね。
同時に、この種の不正に関する仮説、すなわちここ数年続いている一連の、旭化成や東洋ゴム、神戸製鋼、日産らの件はそれぞれ特異な事例というわけではなく、製造業全体に共通する不正、その一端に過ぎないだろう、という懐疑的な見方が、強力に裏付けられたものと言えるでしょう。
今回明らかになったのは自動車タイヤ向け材料の強度偽装。少し足りない位いいだろう、と考えたそうです。そうですか。
急遽開かれる事になったその釈明会見では、 神戸製鋼の件が無ければ公表はしなかっただろうと臆面もなく認めてもいます。不正を把握した後も1年以上に渡って公表せず、顧客とは個別に確認を進めていたというのですから、後で公表するつもりだった、といった類の言い訳のしようもなかっただけなのでしょうけど、目も当てられません。
ともあれ、東レや三菱マテのような、誰もが認める各分野の業界トップであり、確固たる地位、事業基盤を有し、少なくとも、不正をしなければ立ち行かないような事情があるわけでもない筈の大企業までもが、こぞって組織的な不正に手を染めていたという、残念という表現では到底足りない事実が明らかになってしまいました。
こういう事実を見るにつけ、もうなんと言うか。ああ、もう終わりなんだと思うわけです。いや、とっくに終わっていたんでしょうけど、それを誤魔化す事ももう出来ないんだと。かつての日本株式会社と言われ、品質だとか顧客の信頼だとか、製造業に携わる者が拠り所にしていたような、侵すべからざる一線、それらに付随する当事者の誇りや、周囲の抱いていただろう敬意も、成長のネタが切れた時点で中国はじめ他の後発プレイヤーの競争力の前に、単なる理想論や精神論のような、建前に過ぎない幻想に過ぎなくなっていたという事実。その、現場に近い人間の誰しもが知っていただろう現実の前に、建前を維持する事も出来なくなり、瓦解し、雪崩を打つようにして明るみに出た、という、それだけの事なのでしょう。
言うまでもなく、同情の余地は全くありません。速やかに被害を補償し、十全に責任を取る他に選択肢もありません。その結果、各社が顧客を失って追い込まれ、あるいは国内の製造業自体が消滅しようとも、それも自業自得というしかないのです。もちろん、東レはじめ不正各社のカバーする製品領域は広く、これから幾らでも余罪も出るでしょうし、そちらも併せて責任を負うべきものである事は言うまでもありませんが。
次は何処でしょう。実際の所、殆どのメーカーと担当者、責任者が揃って戦々恐々としているんでしょうし、もはや何処で火が上がっても驚くにはあたらないのでしょうけど、取り返しはつかないのだから、この上は潔く腹を切るべきだと思うのです。談合がよく取り沙汰される自動車部品の各メーカーなんかは当然その前科的にも業界の体質的にも色々怪しまれてそうですが、さて。
東レ、子会社でデータ改ざん タイヤ部品など149件
[関連記事 [biz law] 三菱マテも偽装、かつ10ヶ月隠蔽]
[関連記事 [biz] Uberが大規模情報漏洩、かつ1年超隠蔽]
[関連記事 [biz law] 不正体質という不治の病]
[関連記事 [biz] 神戸製鋼がアルミ・銅製品の強度・寸法偽装10年超]
[関連記事 [biz law] 悪質極まる東亜建設工業の空港耐震工事詐欺、すら普通に感じる現状]
[関連記事 [biz law] 東洋ゴム社製免震装置材料の性能評価偽装発覚に]
[関連記事 [biz] 腐敗肉の蔓延判明で外食大手等が総崩れ]
[関連記事 [biz law] 25年不正を[biz law] 25年不正を隠蔽し果せた戦慄すべき三菱自の組織力と、混沌とする先行きについて]
[関連記事 [biz law] 三菱自、主力車種ほぼ全滅]
[関連記事 [biz law] 懲りない三菱自動車、主力軽自動車の燃費改竄詐欺]
同時に、この種の不正に関する仮説、すなわちここ数年続いている一連の、旭化成や東洋ゴム、神戸製鋼、日産らの件はそれぞれ特異な事例というわけではなく、製造業全体に共通する不正、その一端に過ぎないだろう、という懐疑的な見方が、強力に裏付けられたものと言えるでしょう。
今回明らかになったのは自動車タイヤ向け材料の強度偽装。少し足りない位いいだろう、と考えたそうです。そうですか。
急遽開かれる事になったその釈明会見では、 神戸製鋼の件が無ければ公表はしなかっただろうと臆面もなく認めてもいます。不正を把握した後も1年以上に渡って公表せず、顧客とは個別に確認を進めていたというのですから、後で公表するつもりだった、といった類の言い訳のしようもなかっただけなのでしょうけど、目も当てられません。
ともあれ、東レや三菱マテのような、誰もが認める各分野の業界トップであり、確固たる地位、事業基盤を有し、少なくとも、不正をしなければ立ち行かないような事情があるわけでもない筈の大企業までもが、こぞって組織的な不正に手を染めていたという、残念という表現では到底足りない事実が明らかになってしまいました。
こういう事実を見るにつけ、もうなんと言うか。ああ、もう終わりなんだと思うわけです。いや、とっくに終わっていたんでしょうけど、それを誤魔化す事ももう出来ないんだと。かつての日本株式会社と言われ、品質だとか顧客の信頼だとか、製造業に携わる者が拠り所にしていたような、侵すべからざる一線、それらに付随する当事者の誇りや、周囲の抱いていただろう敬意も、成長のネタが切れた時点で中国はじめ他の後発プレイヤーの競争力の前に、単なる理想論や精神論のような、建前に過ぎない幻想に過ぎなくなっていたという事実。その、現場に近い人間の誰しもが知っていただろう現実の前に、建前を維持する事も出来なくなり、瓦解し、雪崩を打つようにして明るみに出た、という、それだけの事なのでしょう。
言うまでもなく、同情の余地は全くありません。速やかに被害を補償し、十全に責任を取る他に選択肢もありません。その結果、各社が顧客を失って追い込まれ、あるいは国内の製造業自体が消滅しようとも、それも自業自得というしかないのです。もちろん、東レはじめ不正各社のカバーする製品領域は広く、これから幾らでも余罪も出るでしょうし、そちらも併せて責任を負うべきものである事は言うまでもありませんが。
次は何処でしょう。実際の所、殆どのメーカーと担当者、責任者が揃って戦々恐々としているんでしょうし、もはや何処で火が上がっても驚くにはあたらないのでしょうけど、取り返しはつかないのだから、この上は潔く腹を切るべきだと思うのです。談合がよく取り沙汰される自動車部品の各メーカーなんかは当然その前科的にも業界の体質的にも色々怪しまれてそうですが、さて。
東レ、子会社でデータ改ざん タイヤ部品など149件
[関連記事 [biz law] 三菱マテも偽装、かつ10ヶ月隠蔽]
[関連記事 [biz] Uberが大規模情報漏洩、かつ1年超隠蔽]
[関連記事 [biz law] 不正体質という不治の病]
[関連記事 [biz] 神戸製鋼がアルミ・銅製品の強度・寸法偽装10年超]
[関連記事 [biz law] 悪質極まる東亜建設工業の空港耐震工事詐欺、すら普通に感じる現状]
[関連記事 [biz law] 東洋ゴム社製免震装置材料の性能評価偽装発覚に]
[関連記事 [biz] 腐敗肉の蔓延判明で外食大手等が総崩れ]
[関連記事 [biz law] 25年不正を[biz law] 25年不正を隠蔽し果せた戦慄すべき三菱自の組織力と、混沌とする先行きについて]
[関連記事 [biz law] 三菱自、主力車種ほぼ全滅]
[関連記事 [biz law] 懲りない三菱自動車、主力軽自動車の燃費改竄詐欺]
11/24/2017
[biz law] 三菱マテも偽装、かつ10ヶ月隠蔽
流石三菱、と言うべきでしょうか。三菱マテリアルが樹脂・銅・アルミの各部品、部材について、不良品の検査結果を偽装して出荷していた事が発覚した件、既に広く報道されているところですが、同社・同グループの持つ、著しい傲慢さと姑息さが共に存分に反映されてしまっているように見えます。その辺は25年に渡って隠し続けた自動車の燃費偽装がバレた際のそれと全く同じです。
本件犯行による被害、すなわちOリング等の部品が規格を満たさない、という事実がもたらし得る結果の深刻さは今更言うまでもありません。航空機や自動車類はじめ、製造・管理設備、各種インフラに至るまで、気密性や密封性が失われれば、機器や設備に重大な障害をもたらし、あるいは大惨事に直結しかねない類の用途も数知れません。件数も桁違いな点も考慮すれば、神戸製鋼の例よりもさらに悪質かつ深刻と評価すべきものでしょう。
にもかかわらず、同社は本件偽装を把握したとされる2017年2月から今に至るまで、9ヶ月もの間その事実を公表しなかったばかりか、そうと知ってなお不良品を偽装して出荷し続けていた、というのです。この点からしても、まず同社は隠し通し、偽装も続けるつもりだったのでしょうけれども、おそらくは神戸製鋼等の件等から顧客が行ったであろう部品類の検査等を通じて発覚した、という事ではないかと推測されます。反省も自浄もかけらもするそぶりを見せないその態度はまさに三菱。
で、その多分に追い込まれてした発表に際しても、この期に及んで納入先を隠し、あるいは顧客と安全性を確認済みとして一部は当初の公表から外しもする始末。すなわち、自社で問題ない事を確認したし、未確認のものも自分たちが確認中だから知らせる必要はない、黙って待ってろ、というのです。もはや誰ひとりとして同社の言うことを信用する者はいないのに。自分たちが何をやったのか、やっているのか、全く以って理解していないとしか考えられません。
ただ、流石に三菱マテは最大手の一角ですから、本件が致命傷になるのかは正直よくわかりませんし、少なくとも同社並びにその社員が、喉元過ぎれば、程度で大したことはない、程度に高をくくっているだろう事は疑いようがありません。だからこそ隠蔽もしたし、多分に未だにしている余罪もあるのだろうし、個々の社員や部門が責任逃れに走り、あるいは押し付け合いをした結果として、同社の傲慢で姑息な態度がある、という事なのでしょうか。
社会や取引先から加えられる激しい非難も、それが単なる言説に留まる限り何の意味もない、とばかりに無視を決め込む同社の、その遺憾極まる態度が多少でも改められるか否かは、専ら実際に同社に事業上与えられるペナルティによるのでしょう。この点、取引先は実際問題として悩ましい事は色々あるのでしょうけれども、市場と業界、ひいては社会の公正のため、容赦なく損害賠償の請求ないし調達先の変更等の、同社が堪えるだけの、致命的ともなりうるだろう程度のペナルティを与え、それによって同社のような反社会的な企業が更正あるいは淘汰されるよう動く事を期待したいと思います。
[関連記事 [biz] Uberが大規模情報漏洩、かつ1年超隠蔽]
[関連記事 [biz law] 不正体質という不治の病]
[関連記事 [biz] 神戸製鋼がアルミ・銅製品の強度・寸法偽装10年超]
[関連記事 [biz law] 悪質極まる東亜建設工業の空港耐震工事詐欺、すら普通に感じる現状]
[関連記事 [biz law] 東洋ゴム社製免震装置材料の性能評価偽装発覚に]
[関連記事 [biz] 腐敗肉の蔓延判明で外食大手等が総崩れ]
[関連記事 [biz law] 25年不正を[biz law] 25年不正を隠蔽し果せた戦慄すべき三菱自の組織力と、混沌とする先行きについて]
[関連記事 [biz law] 三菱自、主力車種ほぼ全滅]
[関連記事 [biz law] 懲りない三菱自動車、主力軽自動車の燃費改竄詐欺]
本件犯行による被害、すなわちOリング等の部品が規格を満たさない、という事実がもたらし得る結果の深刻さは今更言うまでもありません。航空機や自動車類はじめ、製造・管理設備、各種インフラに至るまで、気密性や密封性が失われれば、機器や設備に重大な障害をもたらし、あるいは大惨事に直結しかねない類の用途も数知れません。件数も桁違いな点も考慮すれば、神戸製鋼の例よりもさらに悪質かつ深刻と評価すべきものでしょう。
にもかかわらず、同社は本件偽装を把握したとされる2017年2月から今に至るまで、9ヶ月もの間その事実を公表しなかったばかりか、そうと知ってなお不良品を偽装して出荷し続けていた、というのです。この点からしても、まず同社は隠し通し、偽装も続けるつもりだったのでしょうけれども、おそらくは神戸製鋼等の件等から顧客が行ったであろう部品類の検査等を通じて発覚した、という事ではないかと推測されます。反省も自浄もかけらもするそぶりを見せないその態度はまさに三菱。
で、その多分に追い込まれてした発表に際しても、この期に及んで納入先を隠し、あるいは顧客と安全性を確認済みとして一部は当初の公表から外しもする始末。すなわち、自社で問題ない事を確認したし、未確認のものも自分たちが確認中だから知らせる必要はない、黙って待ってろ、というのです。もはや誰ひとりとして同社の言うことを信用する者はいないのに。自分たちが何をやったのか、やっているのか、全く以って理解していないとしか考えられません。
ただ、流石に三菱マテは最大手の一角ですから、本件が致命傷になるのかは正直よくわかりませんし、少なくとも同社並びにその社員が、喉元過ぎれば、程度で大したことはない、程度に高をくくっているだろう事は疑いようがありません。だからこそ隠蔽もしたし、多分に未だにしている余罪もあるのだろうし、個々の社員や部門が責任逃れに走り、あるいは押し付け合いをした結果として、同社の傲慢で姑息な態度がある、という事なのでしょうか。
社会や取引先から加えられる激しい非難も、それが単なる言説に留まる限り何の意味もない、とばかりに無視を決め込む同社の、その遺憾極まる態度が多少でも改められるか否かは、専ら実際に同社に事業上与えられるペナルティによるのでしょう。この点、取引先は実際問題として悩ましい事は色々あるのでしょうけれども、市場と業界、ひいては社会の公正のため、容赦なく損害賠償の請求ないし調達先の変更等の、同社が堪えるだけの、致命的ともなりうるだろう程度のペナルティを与え、それによって同社のような反社会的な企業が更正あるいは淘汰されるよう動く事を期待したいと思います。
[関連記事 [biz] Uberが大規模情報漏洩、かつ1年超隠蔽]
[関連記事 [biz law] 不正体質という不治の病]
[関連記事 [biz] 神戸製鋼がアルミ・銅製品の強度・寸法偽装10年超]
[関連記事 [biz law] 悪質極まる東亜建設工業の空港耐震工事詐欺、すら普通に感じる現状]
[関連記事 [biz law] 東洋ゴム社製免震装置材料の性能評価偽装発覚に]
[関連記事 [biz] 腐敗肉の蔓延判明で外食大手等が総崩れ]
[関連記事 [biz law] 25年不正を[biz law] 25年不正を隠蔽し果せた戦慄すべき三菱自の組織力と、混沌とする先行きについて]
[関連記事 [biz law] 三菱自、主力車種ほぼ全滅]
[関連記事 [biz law] 懲りない三菱自動車、主力軽自動車の燃費改竄詐欺]
11/22/2017
[PC] 現行Intel製チップのファームウェアの大半に脆弱性発覚
また面倒な・・・。ここ数年の間にリリースされたIntel製CPU及びチップセットを採用したPC、サーバの大半に共通する脆弱性が発覚してしまいました。
具体的には、第6,7,8世代のCoreシリーズ、同世代のXeon、AtomのC3000系、Apollo LakeのE3900系とPentium、あとNとJシリーズ。現在流通しているIntel系CPUを積んだPC、サーバの殆どが該当する事になります。これだけ見ると、ちょっと何言ってるかわからないレベルで洒落になりませんね。
本件問題の存在箇所は、Intel Management Engine(ME)、Intel Server Platform Service(SPS)、Intel Trusted Execution Engine(TXE)の各機能の部分(のファームウェア)です。いずれもシステム内での起動等から一連の処理について検証を行い、信頼されたもののみが実行されるよう制御するローレベルのサービスです。一般のユーザは使わない、というか気にもしない部分です。何それ?となった人も多いのではないでしょうか。
脆弱性の内容は、これらの機能がOSの外で行う検証等のプロセス内でオーバーフロー等を起こす事で発生するもので、要するに権限外で任意のコードを実行出来るというありふれた、しかし最悪のものです。ただ、今の所USB等の物理アクセスが条件とされているので、とりあえず物理サイトの管理を厳密にすれば攻撃は回避可能とのこと。本当でしょうか?この種のセキュアな制御機能というのは、特にサーバ等ではネットワーク経由で利用されるものなところ、リモートから乗っ取られる危険はないのか、と正直眉唾な気もしますけれども、一応信用する他ないのでしょう。
(追記:続報によれば、大半は物理アクセスが必要なものの、少なくとも1件のMEに存在する脆弱性はネットワーク経由で悪用可能との事でした。)
本来セキュアな筈の起動時のシーケンスに割り込んで任意のコードを実行させる事が出来る、とかそういう類の脆弱性という事なのでしょうか。そうであれば、元よりその辺の、セキュアブートだとかの類の機能を使用していない大半のユーザにとっては、元から使用してもいない機能が無力化されるに過ぎず、従って取り立てて気にする必要もなく、放置してよい、という結論になるわけですが。そうならそれは喜んでいい話ではあるのでしょう。この点、ネットワーク経由で悪用され得るか否かで真逆の結論になるだろうところ、やはりそこは気にかかりますけれども。
(追記:上記追記の通り、真逆でした。一般ユーザも放置してはいけません。)
とは言え、その辺の詳細は考えても仕方ないとして。何にせよ、本機能を使用している企業等のユーザについては、この機に同機能の使用を取りやめる、というのでもない限り、対応しないという選択肢はないでしょう。
しかるに、本件脆弱性の問題は、これがハードウェア、それもローレベルに存在し、その修正にはファームを変更しなければならない、という点にあるように思われます。というのも、当然ながら、ファームはマザーボード毎、メーカー毎に異なるものですから、原則として各メーカーが個々に対処する必要があります。しかし、このレベルの修正はそう簡単に出来るものではありません。修正ファームの作成にも相当の手間がかかり、適用するに際しても小さくないリスクが存在する上に、適用時にはシステムを停止させて、相応の検証も行わなければなりません。しかも、この種のファームウェアはその適用方法もまちまちで、場合によっては一台ずつ手作業が発生する事もあります。SEにかかる負担は小さいものでは有り得ないでしょう。なんという面倒な事をしでかしてくれたのか、というSE達の怨嗟の声が聞こえてきそうです。
本件は専らIntelの過失によるものであり、全ての責任はIntelにあります。そうである以上、Intelはユーザからその対処に要したコストに応じた損害賠償を要求されても文句を言えないでしょう。特に、本件機能を用いるサービスは主に大規模なビジネスユーザ向けに、それなり以上に高額のオプション料金を支払って提供されているものだろうわけで、よりによってそれがこういう事になって、生じるコストは小さいものではありえないし、遺憾に思わないユーザはいないでしょう。さてどう始末をつけるんでしょうね。
なお、本件脆弱性の有無は基本的にCPUの型番で判別出来ますが、より確実に確認するための専用のツールがIntelから提供されています。Windows版とLinux版がそれぞれあり、Windows版は7,8,10対応でGUI版もあり、Linux版は16.04LTSもしくはRedhat7.2に対応でCUIのみです。
というわけで、私の所でも一通りツールを動かして確認してみました。 結果としては、上記リストに該当していた1台のみが脆弱性ありと判定され、後は問題なしと出力されました。該当した1台は、先日新調したApollo Lake(J3455)のサーバです。当該機のOSはUbuntu17.10のServer版で、その他のPC、サーバ類も大半が17.10でしたが、ツールは問題なく動作しました。Windows機は10と7の機種で実行してみましたが、これも問題なし。その手順と出力内容は以下の通りです。
<確認ツール>
[配布ファイル名]
・Linux版 SA00086_Linux.tar.gz
・Windows版 SA00086_Windows.zip
[ツールのダウンロードサイト]
https://downloadcenter.intel.com/download/27150
<確認ツールの動作コマンドと実行結果>
[Linux版の場合]
配布ファイルを解凍すると出力される下記スクリプトをコンソールから実行。なお実行ファイルはpythonのスクリプトにつき、実行にはpythonのインストールが必要です。出力中、[Risk Assessment]の項目が判定結果。問題なしの場合は、[not vulnerable]とだけ表示され、問題ありの場合は[vulnerable]となって、製造元にコンタクトを取るよう促す説明文が追加で表示されます。
$ sudo ./intel_sa00086.py
・Linux版出力結果(問題なしの場合)-----
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: (実行日時) GMT
*** Host Computer Information ***
Name: (ホスト名)
Manufacturer: (マザーボードメーカー名)
Model: (マザーボード型番)
Processor Name: Intel(R) Core(TM) i3-2100T CPU @ 2.50GHz
OS Version: Ubuntu 17.10 artful (4.13.0-16-generic)
*** Intel(R) ME Information ***
Engine: Intel(R) Management Engine
Version: 7.0.4.1197
SVN: 0
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is not vulnerable.
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
-----ここまで
・Linux版出力結果(問題ありの場合)-----
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: (実行日時) GMT
*** Host Computer Information ***
Name: (ホスト名)
Manufacturer: System manufacturer
Model: System Product Name
Processor Name: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz
OS Version: Ubuntu 17.10 artful (4.13.0-16-generic)
*** Intel(R) ME Information ***
Engine: Intel(R) Trusted Execution Engine
Version: 3.0.1.1105
SVN: 0
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is vulnerable.
Explanation:
The detected version of the Intel(R) Trusted Execution Engine firmware is considered vulnerable for INTEL-SA-00086.
Contact your system manufacturer for support and remediation of this system.
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
-----ここまで
[Windows版の場合]
配布ファイルを解凍し、出力されるファイル中、[DiscoveryTool.GUI]中の[Intel-SA-00086-GUI.exe]を実行。すると、チェックが実行され、数秒後に下図のようにダイアログに結果が表示されます。判定結果は一番上です。この例では脆弱性なし。
というわけで、脆弱性ありの判定が1台出たわけですが、現時点ではどうする事も出来ません。というのも、2017/11/22時点で対応済のファームウェアを提供しているところは無い模様だからです。今回の対象はASUS製のJ3455M-Eですが、当然のように公式サポートには本件に関する説明すらない始末。当のIntelからして自社製NUC等について未対応で、2017/12にリリース予定というのだから酷い話です。判定ツールの指示に従ったユーザからコンタクトを受けた製造元も対応に困るでしょうに。アウトの判定だけして放置、というのは幾ら何でもあんまりです。ユーザ側としては、悶々としつつ、あるいは悪意に脅えつつ待つ他ないし、ベンダも顧客を宥めながらこれまた待つしかないだろうわけなのですけれども。
しかし、じっと待って、ようやく修正ファームが提供されたとしても、それで解決にはならないのがまた。だって、適用対象は下手しなくてもここ数年で入れた端末全部ですよ?顧客のシステムを止めるわけにもいかないし、代替機を出そうにも数が半端ないしで、頭を抱えているSEも多そうです。 シンクライアントやそれに近いレベルでクラウド化しているところは何とでもなるんでしょうけど、クライアント側で色々入れてる所は大変そうです。ご愁傷さま、と言うしかないのでしょうけれども。
(追記)
遠隔で利用可能な脆弱性が含まれている事が発覚したからか、DELL、HP、Lenovo等の大手は11/23時点でパッチを用意したようです。流石迅速ですね。ただ、モデル毎にリリース予定日が1か月後だったり二ヶ月後だったり未定だったりまちまちなところもあり、その辺は今いちな感じではあるのですけれども。一方我らがASUSは未だ音沙汰すらなし。まあ多分にPCメーカーのOEM周りへの対応を優先して、比較的ユーザの少ない自作ユーザ側は後回しにしてるとかそういう話なのかもしれませんけど、この放置っぷりは残念です。
Intel® Management Engine Critical Firmware Update (Intel SA-00086)
Intel Q3’17 ME 11.x, SPS 4.0, and TXE 3.0 Security Review Cumulative Update
[関連記事 [PC note] 今更ながらのApollo lakeが意外といい感じ]
具体的には、第6,7,8世代のCoreシリーズ、同世代のXeon、AtomのC3000系、Apollo LakeのE3900系とPentium、あとNとJシリーズ。現在流通しているIntel系CPUを積んだPC、サーバの殆どが該当する事になります。これだけ見ると、ちょっと何言ってるかわからないレベルで洒落になりませんね。
本件問題の存在箇所は、Intel Management Engine(ME)、Intel Server Platform Service(SPS)、Intel Trusted Execution Engine(TXE)の各機能の部分(のファームウェア)です。いずれもシステム内での起動等から一連の処理について検証を行い、信頼されたもののみが実行されるよう制御するローレベルのサービスです。一般のユーザは使わない、というか気にもしない部分です。何それ?となった人も多いのではないでしょうか。
脆弱性の内容は、これらの機能がOSの外で行う検証等のプロセス内でオーバーフロー等を起こす事で発生するもので、要するに権限外で任意のコードを実行出来るというありふれた、しかし最悪のものです。ただ、今の所USB等の物理アクセスが条件とされているので、とりあえず物理サイトの管理を厳密にすれば攻撃は回避可能とのこと。本当でしょうか?この種のセキュアな制御機能というのは、特にサーバ等ではネットワーク経由で利用されるものなところ、リモートから乗っ取られる危険はないのか、と正直眉唾な気もしますけれども、一応信用する他ないのでしょう。
(追記:続報によれば、大半は物理アクセスが必要なものの、少なくとも1件のMEに存在する脆弱性はネットワーク経由で悪用可能との事でした。)
本来セキュアな筈の起動時のシーケンスに割り込んで任意のコードを実行させる事が出来る、とかそういう類の脆弱性という事なのでしょうか。そうであれば、元よりその辺の、セキュアブートだとかの類の機能を使用していない大半のユーザにとっては、元から使用してもいない機能が無力化されるに過ぎず、従って取り立てて気にする必要もなく、放置してよい、という結論になるわけですが。そうならそれは喜んでいい話ではあるのでしょう。この点、ネットワーク経由で悪用され得るか否かで真逆の結論になるだろうところ、やはりそこは気にかかりますけれども。
(追記:上記追記の通り、真逆でした。一般ユーザも放置してはいけません。)
とは言え、その辺の詳細は考えても仕方ないとして。何にせよ、本機能を使用している企業等のユーザについては、この機に同機能の使用を取りやめる、というのでもない限り、対応しないという選択肢はないでしょう。
しかるに、本件脆弱性の問題は、これがハードウェア、それもローレベルに存在し、その修正にはファームを変更しなければならない、という点にあるように思われます。というのも、当然ながら、ファームはマザーボード毎、メーカー毎に異なるものですから、原則として各メーカーが個々に対処する必要があります。しかし、このレベルの修正はそう簡単に出来るものではありません。修正ファームの作成にも相当の手間がかかり、適用するに際しても小さくないリスクが存在する上に、適用時にはシステムを停止させて、相応の検証も行わなければなりません。しかも、この種のファームウェアはその適用方法もまちまちで、場合によっては一台ずつ手作業が発生する事もあります。SEにかかる負担は小さいものでは有り得ないでしょう。なんという面倒な事をしでかしてくれたのか、というSE達の怨嗟の声が聞こえてきそうです。
本件は専らIntelの過失によるものであり、全ての責任はIntelにあります。そうである以上、Intelはユーザからその対処に要したコストに応じた損害賠償を要求されても文句を言えないでしょう。特に、本件機能を用いるサービスは主に大規模なビジネスユーザ向けに、それなり以上に高額のオプション料金を支払って提供されているものだろうわけで、よりによってそれがこういう事になって、生じるコストは小さいものではありえないし、遺憾に思わないユーザはいないでしょう。さてどう始末をつけるんでしょうね。
なお、本件脆弱性の有無は基本的にCPUの型番で判別出来ますが、より確実に確認するための専用のツールがIntelから提供されています。Windows版とLinux版がそれぞれあり、Windows版は7,8,10対応でGUI版もあり、Linux版は16.04LTSもしくはRedhat7.2に対応でCUIのみです。
というわけで、私の所でも一通りツールを動かして確認してみました。 結果としては、上記リストに該当していた1台のみが脆弱性ありと判定され、後は問題なしと出力されました。該当した1台は、先日新調したApollo Lake(J3455)のサーバです。当該機のOSはUbuntu17.10のServer版で、その他のPC、サーバ類も大半が17.10でしたが、ツールは問題なく動作しました。Windows機は10と7の機種で実行してみましたが、これも問題なし。その手順と出力内容は以下の通りです。
<確認ツール>
[配布ファイル名]
・Linux版 SA00086_Linux.tar.gz
・Windows版 SA00086_Windows.zip
[ツールのダウンロードサイト]
https://downloadcenter.intel.com/download/27150
<確認ツールの動作コマンドと実行結果>
[Linux版の場合]
配布ファイルを解凍すると出力される下記スクリプトをコンソールから実行。なお実行ファイルはpythonのスクリプトにつき、実行にはpythonのインストールが必要です。出力中、[Risk Assessment]の項目が判定結果。問題なしの場合は、[not vulnerable]とだけ表示され、問題ありの場合は[vulnerable]となって、製造元にコンタクトを取るよう促す説明文が追加で表示されます。
$ sudo ./intel_sa00086.py
・Linux版出力結果(問題なしの場合)-----
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: (実行日時) GMT
*** Host Computer Information ***
Name: (ホスト名)
Manufacturer: (マザーボードメーカー名)
Model: (マザーボード型番)
Processor Name: Intel(R) Core(TM) i3-2100T CPU @ 2.50GHz
OS Version: Ubuntu 17.10 artful (4.13.0-16-generic)
*** Intel(R) ME Information ***
Engine: Intel(R) Management Engine
Version: 7.0.4.1197
SVN: 0
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is not vulnerable.
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
-----ここまで
・Linux版出力結果(問題ありの場合)-----
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: (実行日時) GMT
*** Host Computer Information ***
Name: (ホスト名)
Manufacturer: System manufacturer
Model: System Product Name
Processor Name: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz
OS Version: Ubuntu 17.10 artful (4.13.0-16-generic)
*** Intel(R) ME Information ***
Engine: Intel(R) Trusted Execution Engine
Version: 3.0.1.1105
SVN: 0
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is vulnerable.
Explanation:
The detected version of the Intel(R) Trusted Execution Engine firmware is considered vulnerable for INTEL-SA-00086.
Contact your system manufacturer for support and remediation of this system.
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
-----ここまで
[Windows版の場合]
配布ファイルを解凍し、出力されるファイル中、[DiscoveryTool.GUI]中の[Intel-SA-00086-GUI.exe]を実行。すると、チェックが実行され、数秒後に下図のようにダイアログに結果が表示されます。判定結果は一番上です。この例では脆弱性なし。
というわけで、脆弱性ありの判定が1台出たわけですが、現時点ではどうする事も出来ません。というのも、2017/11/22時点で対応済のファームウェアを提供しているところは無い模様だからです。今回の対象はASUS製のJ3455M-Eですが、当然のように公式サポートには本件に関する説明すらない始末。当のIntelからして自社製NUC等について未対応で、2017/12にリリース予定というのだから酷い話です。判定ツールの指示に従ったユーザからコンタクトを受けた製造元も対応に困るでしょうに。アウトの判定だけして放置、というのは幾ら何でもあんまりです。ユーザ側としては、悶々としつつ、あるいは悪意に脅えつつ待つ他ないし、ベンダも顧客を宥めながらこれまた待つしかないだろうわけなのですけれども。
しかし、じっと待って、ようやく修正ファームが提供されたとしても、それで解決にはならないのがまた。だって、適用対象は下手しなくてもここ数年で入れた端末全部ですよ?顧客のシステムを止めるわけにもいかないし、代替機を出そうにも数が半端ないしで、頭を抱えているSEも多そうです。 シンクライアントやそれに近いレベルでクラウド化しているところは何とでもなるんでしょうけど、クライアント側で色々入れてる所は大変そうです。ご愁傷さま、と言うしかないのでしょうけれども。
(追記)
遠隔で利用可能な脆弱性が含まれている事が発覚したからか、DELL、HP、Lenovo等の大手は11/23時点でパッチを用意したようです。流石迅速ですね。ただ、モデル毎にリリース予定日が1か月後だったり二ヶ月後だったり未定だったりまちまちなところもあり、その辺は今いちな感じではあるのですけれども。一方我らがASUSは未だ音沙汰すらなし。まあ多分にPCメーカーのOEM周りへの対応を優先して、比較的ユーザの少ない自作ユーザ側は後回しにしてるとかそういう話なのかもしれませんけど、この放置っぷりは残念です。
Intel® Management Engine Critical Firmware Update (Intel SA-00086)
Intel Q3’17 ME 11.x, SPS 4.0, and TXE 3.0 Security Review Cumulative Update
[関連記事 [PC note] 今更ながらのApollo lakeが意外といい感じ]
Subscribe to:
Posts (Atom)