弁財天

ゴフマン「専門家を信じるのではなく、自分自身で考えて判断せよ」

BIOS更新プログラムR1.29.0が/boot/initramfs*.imgを書き換え損なう未必の故意のテロを証明できるのか? update23

2016年5月10日東大柏キャンパスのスパコンに富士通のPRIMERGY8208台の発表。
2016年5月30日AC2がRAIDエラーを発報。マザーボード交換。
2016年6月1日全サーバーのBIOS更新開始。DBx2台リブート、Web1-4成功、Web5がiRMCハングアップ。
2016年6月2日DBx2台はオフラインでiRMC更新不可。UBも同じ。
2016年6月4日DBで破損したmodule.depを修復してdracutマニュアル実行。
2016年6月7日Dシステムでkipmi0プロセスが暴走。
2016年6月8日リブート時にメーカーのロゴ画面で起動がとまる。iRMCのメッセージ。電源を抜いてリセット。
2016年6月9日夕方会社から圧力w Web記事とツイ垢を非公開にw
2016年6月10日午前西中島のDNS参照(プロバイダ)が細工される。公開DNSも2つだけ使用状態。36個ランダムに設定して回避。
2016年6月10日ゴルフで主要関係者が職場から消える。N社社員も。
2016年6月10日午後ハードウェアベンダーがBIOSのバグを認める。
2016年6月10日糖蜜が国債のプライマリディーラ資格をニチギンに返上して独自のビットコインを発行
2016年6月24日Brexit国民投票でEU離脱が決定。
2016年6月25日午後現行L3SWがループ検知。

サーバーのBIOSを更新したらよりによってDBサーバが2つともネットにつながらなくなった。Linuxは起動したとか言ってる。何かおもいきり壊したみたいだ。(2016年6月1日) ゲロゲロ。

dmesgで見ると eno1とeno2インターフェイスが見えなくなっていた。それをまとめてbond0に設定していて、11gR2のPublicインターフェイスでもあり、DNSサーバーでもあった為、システム全体が死亡。

そもそもBIOSの更新でこんなピンポイントで破壊される理由が不明。2台存在するDBサーバの冗長化していた2つのネットワーク・インターフェイスを使用不可能にすることでシステム全体を止めるなんて、何かサイバーテロみたいなw

Request for unknown module key 'F Software: F BIOS DB FJMW Certificate: 74ad…47a9' err -11
こういうのが4か所でてますなぁ。
Request for unknown module key 'F Technology Solutions: FTS Linux module signing key: febf…42f3' err -11
ん?PCLUSTERw 当てるBIOSを間違えたのかすら。
これ

F BIOS DB FJMW Certificate: XXXXXXXX' err -11
は無害なんだと。マニュアル


最新のBIOSは
P RX2530 M1
V5.0.0.9 - R1.29.0 (23/03/2016)

ん?ub1fのBIOSのバージョンはV5.0.0.9 R1.27.0 for D3279-A1xになってる。 ub1fの更新はまだとか。

単純にBIOSを上げると言ってるが、バージョンアップしたBIOSと噛み合うLAN、Fibre Channel、RAIDドライバーの更新に影響が派生していく。
Downloads for P RX2530 M1

うーむ。これってBIOSのバージョンアップて、今さらできないんじゃね?

Changes BIOS V5.0.0.9 R1.28.0 for D3279-Axx 15.01.2016 Changes and Problems fixed: -

P RX2530 M1 UEFI FW changes:

Changes BIOS V5.0.0.9 R1.29.0 for D3279-Axx                 01.04.2016
========================================================================
Changes and Problems fixed:
- update to EFI LSI OPROM 04090000
- resolved issue that boot options are sometimes disappearing from boot
menu if boot from PXE initiated via IRMC has been executed
- resolved the problem of being unable to establish PXE boot on onboard
port 2 via VIOM
- resolved behavior that user password cannot be changed without admin
password by using eLCM RestAPI
- resolved CLP error of Emulex OCe14401 in case of switching from RoCE
to SRIOV mode via VIOM
- Improved error logging (WHEA ID17) for released QLogic FC controller
- Extended IRMC network inventory data for Emulex LPe3100x controller

New features:
- support for Tesla M60 under ESXi 6.0
- support for LOM board D3285


Changes BIOS V5.0.0.9 R1.28.0 for D3279-Axx                 15.01.2016
========================================================================
Changes and Problems fixed:
- resolved missing Network Inventory information in iRMC WebIF
- resolved BIOS parameter restore issues (unexpected SEL, failed restore)
- resolved eLCM F-key issue of failed System boot from selected Image 
- resolved unexpected Boot Priorities after setting boot device via ipmi
- resolved unexpexcted CLP SEL entry in CNA VIOM configuration 

New features:
- support eLCM Rest API feature (Profile Manager) with iRMC >=8.08F
- support UEFI PXE boot with IPv6 


UEFI FW - V5.0.0.9 Release R1.27.0 for D3279-Axx            26.10.2015
========================================================================
Changes and Problems fixed:
- update to Haswell microcode 00000036h
- update to Legacy LSI OPROM A.14.10171446
- update to EFI LSI OPROM 04050000
- resolved system sporadically not boot from selected eLCM Image
- resolved Secure Boot Logo Test fails (missing signature in dbxDefault)
- enable bios setup network stack Ipv4Pxe/Ipv6Pxe based on the VIOM table
- resolved that sometimes non-VIOM boot options disappear from boot list
- allow Bios Flash during running VIOM profile
- update VIOM inventory boot support vor OCe14401B-UX-F, 40G    
- update MAC de-virtualization support for all Skyhawk variants
- update Skyhawk RoCE support
- resolved that Wake-Up Resources LAN (WOL) setting could not be changed

New features:
- add PLX support for special Siemens Adapter CP1623
- add new setup item “CNA Standby” to menu “Onboard Devices Configuration”


UEFI FW - V5.0.0.9 Release 1.25.0 for D3279-Axx               05.08.2015
========================================================================
Changes and Problems fixed:
- update to Haswell microcode 00000032h
- resolved display issues with iRMC Network inventory
- improved settings for IB EDR HCA Bidirectional performance
- resolved Wake On LAN can't be disabled in BIOS setup
- resolved forced RemoteMedia CD-Rom boot failed with "UEFI only"
- resolved LAN1 PXE boot failed even if force LAN boot is enabled and
  powered on by magic packet
- resolved Emulex OCe14401B-U 1-Port 40 GbE is not correctly recognized
  in iRMC WEB IF
- retain serial multiplexer setting after setting iRMC to defaults
- resolved Boot order to be correct with 3 Remote Media Devices
- set correct "Slot Power Limit Value/Scale" for all PCI Express Root Ports
- enable the 8 Gbps FC Qlogic QLE2560, QLE2562 CLP support to deliver
  the adapter WWNs and the FW version to the Platform Network Inventory
resolved missing Network Inventory information in iRMC WebIF -
resolved BIOS parameter restore issues (unexpected SEL, failed restore)
w

BIOSの更新に失敗して元に戻せないパターンなのでマザーボード交換か。 まぁ、このインベントリーデータが破損してしまったのでしょーか。

BIOS更新がうまくいったサーバーといかなかったサーバーの違いはオンボードと、外付けのネットワークカードの違いとか。

CEはBIOSをV5.0.0.9 R1.27.0からV5.0.0.9 R1.29.0へのバージョンアップを試みたと言ってる。

これっていったん外付けのカードを抜いて電源オンとオフ。その後カード挿入で認識するパターンかw 今回の障害で思い出したのはこれw Hacking Team spyware survives on target systems with help of UEFI BIOS rootkit
なぜこれを思いだしたのか?
なぜなら同じ日にノートPCのハードディスク障害が起きてたから。 しかも当日N社社員U氏が研修で不在になってたかーらww

Exploiting UEFI boot script table vulnerability (2015年2月6日)
あー、これってスカウト(scout)だw
「Hacking Team」、BIOSやUEFIに感染するルートキットを利用して自社製品のエージェントをPCに常駐
scoutがキターw

やっぱこれ仕掛けた方がいいのか。
Network Defense ? Catching the Galileo RCS using Snort
Network Defense ? Catching the Galileo RCS using Snort

問題のDBサーバは以前のR1.27.0のBIOSを搭載したマザーボードに交換してもeno1とeno2ポートはオンラインにならなかった。
ありえねー。LinuxからネットワークI/Fが見えない状態だけど、メーカーはハードウェアのトラブルではないと言ってるとか。これはもう何かサボタージュ工作ですな。

そしてBIOS更新プログラムが/boot/initramfs.imgの書き換えてることが判明。 modoribe bondingでカーネルモジュールをロードできなくなってた。 insmodコマンドでbonding.koをロードすると使えるようになる。

BIOSの更新と思ってたら、BIOS更新プログラムがLinuxのブートRAMファイルシステムを書き換え損ねて、カーネルモジュールのロードに失敗したとゆーのが原因だったw
ありえねー。
まったく人騒がせな不治痛BIOSだぁぁ。

さて、ここから話がおもしろくなるのである。 不治痛BIOSにはFreeDOSで更新するオフライン手順が存在することだ。 じゃぁオフラインのBIOS更新プログラムもLinuxのinitramfs.imgを書き換えるのかというとこですな。

ちょっと常識的に考えて異常。BIOS更新プログラムが/boot/initramf.imgにルートキットやスパイウエア、ウイルスの類を仕込んだよーに見えますなw

しかもそんなブートしなくなるかもしれない重要なファイルをバックアップなしに更新し損なうなんて異常でしょ。

で、それはbonding.koをロードできなくなる障害が起きたことから、何かとカーネルモジュールを密かに追加したように見えるw
m9( ゚Д゚) ドーン!
不治痛改め、ドジ痛が世界デビューした瞬間。

ひょっとして、うちのシステムもバグラディシュみたいな不正送金が起きるのかすら?

タイミングとしてはこの後だから犯人はまたしてもケーサツだな。

なにやら作り直したらうまく行ったそーである。たぶんinitramfsか? しかしBIOSの更新がなにやらカーネルモジュールに細工をしようとして失敗したのは事実である。
さて、ここでなおったというのはbondingモジュールが以前と同様にロードされたということ。しかし不治痛のBIOS更新プログラムがカーネルモジュールにどんな細工をしてたのかは不明w

これって、UKのBAEシステムがバングラデシュで見つけたみたいに、バイナリを比較すると、どこか2バイトがNOPに書き換えられてるのでは?などと考えている。
Two bytes to $951m(2016年4月25日)
BAEシステムズのThreat Research Blog「9億5100万ドルへの2バイト」

第384回 Initramfsのしくみ

カーネルはブートローダーによって起動されたあと,ルートファイルシステムをマウントするために,サポートしているすべてのディスクデバイスのドライバを持っている必要があります。

しかしながらこのドライバをすべてカーネルに組み込んでしまうと,カーネルが肥大化してしまいます。しかもそのほとんどは,今使っているディスクデバイスでは不要なドライバです。必要なドライバを必要に応じてロードする仕組みとして「カーネルモジュール」がありますが,今度はその「カーネルモジュール」をどこに保存するのかという問題が発生します。当然のことながら,この時点でルートファイルシステムにはアクセスできません。

そこで出てくるのが「Initramfs」という仕組みです。

まさにこれ。で、今まで使用していたbonding.koがなぜロードできなくなったのか。何やっちゃったの?ですな。

Linux環境にはVirtualBoxのようにinitramfsを更新するインストールは存在する。 しかしそれは/boot下にあるすべてのバージョンのinitramfsを更新するはずだ。 不治痛のBIOS更新は稼働してるバージョンのinitramfsだけを更新した。

オフラインアップデートと呼ばれる、USBからFreeDOSでブートしたBIOS更新ではinitramfsを更新しない。なぜなら動いてるカーネルバージョンがわからないし、DOSの環境ではdracutでinitramfsを作成することができないからだ。

では、不治痛のオンラインアップデート(BIOS更新)はいったい何をやろうとしてたのだろうか?w

RHEL7のinitramfsの展開方法。 How to extract initramfs for RHEL6/7

# /usr/lib/dracut/skipcpio /boot/initramfs-3.10.0-123.el7.x86_64.img | gunzip -c | cpio -i -d
79208 blocks
#
オンラインアップデートしたら更新中にOSのリブートがかかって /lib/modules/3.10.0-hoge/modules.depがファイルサイズゼロになり、 以降dracutでinitramfsを作れなくなったらすい。 ブートしなくなりインストールメディアからブートしてbondingのロードに失敗したinitaramfsからmodules.depを復旧し dracut -f /boot/initramfs-3.10.0-hoge.img 3.10.0-hogeで作成したとか。

おもしろいのはデータベースサーバーはBIOSのオンラインアップデート中に2台とも意図しないリブートを起こしたそうである。

2台のDBサーバ両方をいきなり更新するのではなく1台ずつやれば 隣のサーバーに破損したmodules.depが存在していてコピーできたはず。 さらに似たハード構成のub1fからコピーしてくればよかったのに インストールメディアから復元したために微妙にバージョンがズレてしまったようだ。

なにか意図的に失敗して壊してますな。しかも顧客には何も報告しないままもみ消すみたいだ。これはダメかもしれん。

これ

 NOTE rcu messages, system resets or hangs
Under heavy system load frequent messages "INFO: rcu_sched detected stalls on CPUs/tasks" can occur.
Also spontaneous resets of a server or system hangs during heavy system load can occur.

Workaround:
Please use the kernel parameter

rcupdate.rcu_cpu_stall_suppress=1

Very sporadically the system can hang during boot with a CPU IERR.
Workaround:
Disable USB 3.0 in BIOS (XHCI = Disabled)

An unexpected system reboot or system freeze can occur or a lot of rcu messages are reported.            !!! ATTENTION !!!
Under heavy system load frequent messages "INFO: rcu_sched detected stalls on CPUs/tasks" can occur.
Also spontaneous resets of a server or system hangs during heavy system load can occur.

Workaround:
Please use the kernel parameter

rcuupdate.rcu_stall_suppress=1 
BIOS 1.29.0のドキュメントにカーネルパラメータ
rcupdate.rcu_cpu_stall_suppress=1とは別の rcuupdate.rcu_stall_suppress=1があることを発見。
を設定しないと意図しないリブートやハングアップを起こすという記述を見つけたw
ありえねー。

GRUB_TIMEOUT=5
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.retry=7200 rhgb quiet numa=off transparent_hugepage=never thash_entries=131072 scsi_mod.eh_deadline=1 rcupdate.rcu_cpu_stall_suppress=1 crashkernel=256M consoleblank=0 trace_event=block:*,irq:*,mce:*,sched:*,signal:*,workqueue:*,scsi:*,kvm:*,net:* trace_buf_size=25165824"
GRUB_DISABLE_RECOVERY="true"
/etc/default/grub に設定されてたのは rcupdate.rcu_cpu_stall_suppress=1

rcu_sched self-detected stall - Is it a watchdog?
userspace RCU(QSBR)の使い方と解説
Read Copy UpdateでRCU

カーネル空間では古くから問題になっていた物で、その解決策としてRCUというものが使われている。

大雑把に説明すると

大事なデータを読み出してる間にはプリエンプションを禁じる

データを削除する際にはそのスレッドをyieldし続けて他のスレッドに自分の載ってるプロセッサを貸し出す。他のスレッド全部が最低1度でも自分のCPUコアに載った事を確認したら消して良し(何故なら大事なデータを読みかけのスレッドはプリエンプションされないので、自分のCPUコアに載ってこない。載ってきたなら読みかけでない証拠)

という物。これは読み出し側に一切のペナルティが無くて素晴らしい。でも、カーネル空間内だからこそプリエンプションを禁じるとかスレッドのマイグレーションを検知するとかが出来るわけで、ユーザー空間で真似できる代物ではない。*2

そこで、アルゴリズムの力でユーザー空間でこれに近いものを実現しようぜってのがUserspace RCU。

なんのこっちゃ。要するにカーネル内部の排他制御、スピンロックのデッドロック検出ロジックだな。

DBサーバには16個のCPUが搭載されている。WebサーバのBIOS更新が成功したことが RCUのトラブルであることを証明している。

というわけで、RAIDコントローラのバク対応としてBIOSのオンライン更新を試みたところ、 カーネルの糞詰まり検出ロジックが誤動作し、意図しないリブートやハングアップを起こし module.depが破損、initramfsが壊れたというのが真相だった。

/etc/defaults/grubに設定されていたパラメータは、
rcupdate.rcu_cpu_stall_suppress=1で
本当のパラメータは
rcuupdate.rcu_stall_suppress=1だった。

2つあるのだw

どうやら不治痛サポートはrcupdate.rcu_cpu_stall_suppress=1 が正しいと言い張っている。 しかし、このパラメータはHTMLの記述から消えてる。

微妙につづりの違う2つのパラメータが存在することを知らないふりをしてるw
おまいら相変わらず痛いやつらだなw

たぶん彼らは知っててやったのだろう。未必の故意テロですな。 なぜならオレが担当した構築したサーバだけが壊れているからだw
当日N社社員は研修で現場からいなくなっていたことと、 メールで無理矢理責任をなすりつけようとしたこと、 この障害をもみ消そうと試みたこと自体がN社+D社+ハードウェアベンダF社の破壊工作だったことを証明してしまう。

今回ほぼ証明できた「未必の故意」テロは、以前起きたL3SWのリンクが待機系が落ちて、次に実行系が落ちネットから切断されブラックアウトした障害もテロだったことを示唆するのだろう。

現行のUPSのping監視が失敗してたのが、どういうわけか自然治癒したのも、何かLANに細工されていたことを証明する。

開発チームのPCがHinemos接続でセッションが初期化される障害を起こしていたけど、その原因はトレンドマイクロだった。そういえば今回BIOS更新した人はトレンドマイクロの導入も担当してたなぁ。

今回のBIOS更新テロは、今まで起きた事の種明かしみたいになってて非常におもしろい。背景にある体制がぼんやりと見えてくるかんじだ。

面白いと思ったのはトレンドマイクロがブラウザに介入しセッションを初期化することが判明してるのにその事実を無視して、スワンのバグを主張し続けてるとこ。これはある意味自白になってしまっているw

どうも彼らにとっての障害とは自作自演で何かをアピールするもののようだ。こうなると何もやる気はなくなって来る。前回のJQシステム構築時に起きた障害もやつらの自作自演だったと考えれば納得できるものがいくつも思い出せる。困ったもんですなー。

Zシステムの後にDシステムでサイバーテロ発生w(2016年6月7日の夕方)。2つに共通する人物は #D社
これでターゲットがD社だと判明したな。いったい誰がやってるんだろw

なんと。Dでトラブったコンポーネントはkipmi0で、 それはZのiRMCと同じ機能のコンポーネントだった。

kipmiN:kipmi0のCPU使用率が非常に高い。

えぇぇぇぇぇ。ありえねー。 何か大規模なサーバー管理機能がハックされてる感じは否定できない。

この時点で容疑者がほぼ確定してしまってるやんw kipmi0 cpu 100でググるとでるなー。つまりこの嫌がらせの手法を過去に経験した人物w でもこれ、大規模サーバー管理機能なんだろ。そんな沢山サーバーを抱えてるなんて、もっと容疑者が限定されていくやーん ( ^∀^)ゲラゲラ

すっげーわ。誰がやってるんだろ。ヒトじゃないかも。

DシステムはRHEL6なので、対策するとなるとこれだな。

kipmi kernel helper thread kipmi0 is generating high CPU load 

Issue

    The kipmi0 kernel helper thread sometimes goes to 100% CPU usage. Once there, it remains at 100% until the next reboot. After a reboot, things return to normal and then, at a random time later, it goes to 100% again.

Environment

    Red Hat Enterprise Linux 4
    Red Hat Enterprise Linux 5
    Red Hat Enterprise Linux 6
    Out-of-band management hardware that supports the Intelligent Platform Management Interface (IPMI, a systems health and management standard supported by multiple vendors)

Resolution

Proper resolution of this issue requires a fix at the hardware/firmware level.

    Identify the BIOS version installed on the affected system through

# dmidecode

    Identify the Baseboard Management Controller (BMC) firmware version through

# ipmitool mc info

    Check the hardware vendor's support site for newer BIOS and BMC firmware versions and update to them, if possible.
    If the issue persists with the current BIOS and BMC firmware versions, contact the hardware vendor's support organization for assistance.

Workaround for RHEL 6

Since the ipmi_si module was built in to the kernel in RHEL6, the following can be appended to the end of the kernel line in /etc/grub.conf:

ipmi_si.kipmid_max_busy_us=
データセンターでDシステムのサーバーをリブートしたらBIOSのとこで止まって起動しなくなった。iRMCのメッセージがでてるとかw

なんと、このBIOS関連資料のパラメータが間違ってるという事にw
赤い文字で !!!ATTENTION!!! と書いてあるパラメータは存在しないし間違いなんだとw
うはは。どゆこと?

これって将棋のように詰んでね?
1)パラメータが正しいのなら、設定ミスが原因でBIOS更新時にリブートした。Zシステム
2)パラメータが存在しないのなら、ServerView Agent経由でiRMCを遠隔操作された。Dシステム
やっぱ詰んでるわ。

すっげー。ぶったまげた。
JQシステムでTrendmicroとNetScreenとCiscoの裏口が3つ同時に並んだときと同じくらいの驚きですなw

これはもう詰んでしまってるのだから、OracleのPublic YUMが原因だとか新しいストーリーを始めなければしゃーない訳ですな。

別の論点もあって、海外のPユーザーはドキュメントを信じてパラメータを設定するはずな訳で、その時いったいカーネルで何がおきるのか?ですな。

Dで起きたことがZで起きるとなると、これって防ぐ事は可能なのだろうか?

BIOSのアップデートが直接dracutを実行したわけではなく、RHEL7にその仕様がある。WebサーバはRHELのrpmだったわけでOracleのrpmとか未意味な議論だ。

とくかく論理を都合のいいようにねじ曲げていき再導入を急ぐ理由は何なんだ?あとD社の社員が事実のエンジニアを試みてるのも笑える。つまりDシステムのiRMCの破壊も意図的だったことになる。

口裏を合わせる事によって無意味な再導入を急がせる理由は何なんだろう?。たぶんDBのような16個のCPUを持つサーバで仕込んだロジックが壊れ、Linuxがリブートしたりハングアップするのだと思う。それがrcuuとか綴り間違いのパラメータだったのだ。

さて、ここで問題が振り出しに戻ってる事に注意。ハードウェアベンダF社のBIOSのドキュメントでは意図しないリブートの警告とパラメータの設定を推奨していた。しかしサポートが言ってるとおりにパラメータ設定していたにも関わらずBIOS更新でOSが意図せずリブートしたことである。

BIOS更新という特殊なロジックが16個のCPUを搭載したDBサーバで動くとシステムリセットが起きるのだ。これがBIOS更新ではなくOracleの負荷が高くなった時に起きるのか?が顧客側の論点なのだろうけど、たぶん起きないなw

という訳で、データベースサーバを再構築して、BIOSを1.29から1.30にオンライン更新を行うと、すべてRedHat社のrpmで差し替えていたとしても障害は再発してしまうだろう。

問題はそれだけでない。大した根拠もなく闇雲に再構築をプッシュするとこが異常。同時に起きたDシステムの障害では、考えようによってはO市のIDCのセキュリティ問題になるべきで、D社側が偶然だと言い張るのは信用問題になっていくだろう。

ここまでくると、今回のZシステムとDシステムで起きた障害がD社に対するストレステストだったことが理解できるだろう。DBサーバの再構築も何かストレステストの一環なのか。

墓穴をどんどん深く掘ってるのは誰か?

6/10朝、会社のDNS参照がおかしくなっていた。 メールもウェブもできない状態。 しかし今度はDシステムのRemoteCallは問題なく接続されていたそうでw

また1つ墓穴を掘ってる。

会社のDNS障害はルーターのファームウェアとSolarisの/var領域がパンクしていたことが原因の1つだった。 ルータとSolarisの障害ではLinuxのdnsmasqが誤動作してたことを説明できないが、 DNSCryptを導入して対策した。

これってN社、D社、KDS社、ハードウェアベンダF社のサイバーテロだぁ。
BIOSの更新テロはD社Y氏、ハードウェアベンダF社N氏(実在するのか?w)、N社。
Dシステムのサーバーのkipmi0の暴走はD社S氏、D社IDC
KDS社のDNS不具合は再びN社ですな。そういえばこの日も午前中出張とかいって消えてたなw

おもしろかったのはN社F氏がD社Y氏を可哀想だと言ってるとこで、これはヒントになった。 N社F氏とD社Y氏の立場は同じだったのだ。

現行環境で昔AC社が「統合監視」で使ってたSNMPとping監視の接続に、どういう訳かウィルス対策ソフトのパターンファイル更新用として外から中へ80番ポートに穴が空いていた。

そもそもトレンドマイクロのパターンファイルはオフラインで更新することになってる。パターンファイル更新用の裏口があるなんて矛盾してるだろ。

そういえばAPCのUPSがping監視に失敗してたよなぁ。

今年1月にトレンドマイクロのNode.jsを使った遠隔操作の裏口が見つかってる。もちろんこれも80番ポートのHTTPだ。
m9( ゚Д゚) ドーン!

シンガポール政府は10万台のPCをネットから切り離すことを決定。もともとトレンドマイクロはシンガポールに本社があったよなぁ。今は土人の島国にあるのか?w

で、この裏口を使う人物と、この前のDシステムのサーバを暴走させた人物は同じだと思う。

この辺の裏口が選挙前にバレて、じゃあここを閉じれば民主主義に近づき戦争を回避できるのかと思ったりもしたが、何やらSSLアクセラレータを交換してるらすい。 ( ^∀^)ゲラゲラ 参院選前にである。

たぶんこれもストレステストなんだろーな。やみくもに言い訳や弁解する人間を炙り出すストレステスト。すでに何人か引っかかっているw

最近ムサシについて再度調べたことがあって、その結論として、上毛実業はパチンコ経営もしており、どうやら不正選挙の黒幕は警察だという結論になる。

警察庁もNデータ社もGALILEOのユーザだった。ウィキリークスからは #HackingTeam が世界の不正選挙に関与したメールが大量に見つかっている。なので裏口を閉じたのではなく裏口を移動してるのではないかと考えている。

そんなつもりではなかったのだけど、エーデルスタインの「トウキョウバイス」を読んで、リーマンショックの「ヤクザ・リセッション」を起こしたのも、「ヤクザ・リセッション」と名付けたのも、警察のヤクザ部隊であり、誰かが呼んでたように「ポリス・リセッション」なのだというオレ結論。

2016-06-25 13:32:54 syslog received...(Loop! Loop! Loop!)
MESSAGE[syslog received...(Loop! Loop! Loop!)]
FACILITY_ID[実行系L3SW]
PLUGIN_ID[MON_LOG]
MONITOR_ID[log2.l3sw]
MESSAGE_ID[L3SW]
APPLICATION[syslog]
PRIORITY[0]
START_DATE[2016/06/25 13:32:54]
SESSION_ID[20160625133254-000]
TRIGGER_TYPE[監視連動]
TRIGGER_INFO[log2.l3sw(MON_LOG)]
ここまでくると、もはや基地外な人たちですな。
どうやらBrexitの投票操作をしてEUから離脱させてしまったらしい。

Debian vs Ubuntu: ネットワークインタフェースの名前
【その一方で、最近のディストリビューションでは システムのファームウェア/BIOSの登録情報、バス接続情報を元に生成した、 予測可能な名前 (predictable names) をつける機能を提供するようになっています。】

biosdevname rather than systemd network interface names used by default
Bug 965718 - what to do with biosdevname in anacond
そもそもeno1みたいなネットワークインターフェイス名はBIOS/ファームウェアに問い合わせして命名してる。この機能が追加されたのはFedora19(RHEL7)のとき。

従来のBIOSはLinuxがブートした後は用無しだった。Fedora19(RHEL7)から。カーネルがブート後もsystemdがファームウェアに問い合わせてネットワークデバイス名を決める仕様に変わった。Predictable Network Interface Names

RHEL7のsystemdパッケージはudevとdracutと連動してる。稼働中にデバイスの着脱を監視するにはこんな実装になるだろう。 そんな現状を何も知らないF社のBIOSアップデートプログラムがBIOSを更新してしまう。

systemdはF社BIOS応答からdracutでのinitramfsの再構築が必要だと間違った判断をしてinitramfsのリビルドを開始。 しかしその途中、BIOSの更新プログラムにも問題がありCPUの多い(16コア)のシステムをリセット。 dracutの処理が中断しファイルが破損した。

RHEL7のNICのネーミングルール

まとめると次のようになります。

バージョン ハードウェア ネーミングルール
RHEL5 すべて 古典的な「eth0」「eth1」など
RHEL6 一般のマシン 古典的な「eth0」「eth1」など
RHEL6 DELL製のハードウェア biosdevnameによる「em1」「em2」「p1p1」など
RHEL7 一般のマシン Predictable Network Interface Names
RHEL7 DELL製のハードウェア biosdevnameによる「em1」「em2」「p1p1」など

Features/SystemdPredictableNetworkInterfaceNames

F社のオンラインアップデートはsystemdを勘違いさせdracutを走らせてしまう。 そしてコアの多いサーバではBIOSの更新自体がシステムをリセットしてしまう。 この2つが同時に起きたのでファイル破損が起きた。

富士通、パソコン事業をレノボ傘下に 合弁事業で調整 月内合意めざす 2016/10/5 23:36
 富士通はパソコン事業を中国レノボ・グループの傘下に移す方針を固めた。合弁事業とし、レノボが過半を出資する方向で調整している。月内の合意をめざす。富士通は今年2月に非中核分野としてパソコン事業を分社しており、レノボに主導権を渡すことでIT(情報技術)サービス事業などに経営資源を集中する。
 富士通グループでパソコンの企画・開発・製造を手がける部門を合弁会社に移管する。2000人程度が移る見通しだ。パソコン世界首位のレノボの規模を生かし、部品の調達や製造のコストを削減する。
 「FMV」ブランドのパソコンを手がける富士通は、2015年度の出荷台数が400万台だった。出荷の大半を占める国内市場ではシェア2位で、1位のNECレノボ・グループを追っている。だがパソコン市場の縮小などで採算が悪化しており、15年度は「3ケタ億円の赤字」(富士通)だった。
 富士通は東芝のパソコン事業やVAIO(長野県安曇野市)との統合も模索したが、合意に至らなかった。富士通首脳は「短期的に黒字にはできるが2~3年後の状況は不透明だ」とみて、他社との事業統合などの可能性を検討してきた。工場も含めて統合する案を提示したレノボを選んだ。
 レノボは11年にNECと共同出資会社を設立し、NECのパソコン事業を統合した。共同出資会社傘下のNECパーソナルコンピュータとレノボ・ジャパンの2社が国内を中心にパソコン事業を手がけている。NECの「ラヴィ」やレノボの「シンクパッド」などのブランドで展開している。
 新会社は当面、NECレノボとは別のグループとして経営する方針。FMVブランドのパソコン事業を継続し、徐々に企業やブランドの統合を検討していくとみられる。
ぐはは。BIOSテロがバレたから?

結局このBIOS更新テロの背景が判明したのは ブザンソンで筑波大留学生の失踪で判明していく。

ごまめの歯ぎしり » 科学警察研究所

2015.12.16
12月11日に、千葉県柏市にある警察庁の付属機関である科学警察研究所を視察しました。


あら?科警研て千葉県柏市の東大の柏キャンパスの中にあるのかw

東大、科警研、IBM Watson、露のWiMaxクライアントw
なんかいろいろつながったよーな。

国内最高性能の新スパコン=東大と筑波大、運用開始
国内最高性能の新スパコン「オークフォレスト・パックス」の前で握手する東大の中村宏情報基盤センター長(左)と筑波大の梅村雅之計算科学研究センター長=1日午後、千葉県柏市の東大柏キャンパス
 東京大と筑波大は1日、千葉県柏市の東大柏キャンパスに新しいスーパーコンピューター「オークフォレスト・パックス」が完成し、共同で運用を始めたと発表した。性能は神戸市にある理化学研究所のスパコン「京(けい)」を上回り、国内最高という。チェックを経て来年4月から素粒子物理学や地球科学、新素材、創薬などの研究に利用される。  東大情報基盤センターの中島研吾教授は記者会見で、地球温暖化のシミュレーションを例に挙げ「これまでは大気と海洋で別々に計算していたが、両方をカップリングして計算し、より正確な予測ができる」と説明した。(2016/12/01-19:59)
【東京大と筑波大は1日、千葉県柏市の東大柏キャンパスに新しいスーパーコンピューター「オークフォレスト・パックス」が完成】
【 性能は神戸市にある理化学研究所のスパコン「京(けい)」を上回り、 国内最高 】w

あ、みーつけたっと。

富士通のスパコン「Oakforest-PACS」、京を抜いて国内最高位に 日川 佳三=ライター 2016/11/15 ITpro
 富士通は2016年11月15日、同社が構築したクラスター型スーパーコンピュータ「Oakforest-PACS」が、2016年11月のスーパーコンピュータ性能ランキングを示すTOP500リストにおいて、「京」コンピュータを上回り国内最高性能システムとして登録されたと発表した。東京大学と筑波大学が共同で運営する「最先端共同HPC基盤施設(JCAHPC)」の主要計算機として導入した。
 Oakforest-PACSのLINPACKベンチマーク値は1万3554.6テラFLOPS(1秒当たり1京3554兆回の浮動小数点演算)で、TOP500リストの6位に着ける。一方、これまで国内最高位だった京コンピュータのLINPACK値は1万510テラFLOPSで、TOP500リストの7位となった。Oakforest-PACSの総理論演算性能は25ペタFLOPSで、京コンピュータの約2.2倍である。
 Oakforest-PACSは、米インテルの並列処理用プロセッサー「Xeon Phiプロセッサー」を搭載した富士通のサーバー機「PRIMERGY CX600 M1」を8208台使ったクラスターシステムである(関連記事:富士通が25PFLOPSのスパコンを受注、次世代Xeon Phi搭載のPCクラスター、富士通、Xeon Phiプロセッサー搭載のスパコン用サーバーを9月出荷)。Xeon Phiの特徴は、Xeonとの互換性である。GPGPUは並列処理を一から開発する必要があるが、Xeon PhiはXeon上で動作しているx86コードを動作させることができるため、開発生産性が高い。
うはは。不治痛だわw
8208台のPRIMERGYの契約をチラつかせて土人はBIOS更新テロをやらせたんだw。時期が一致w
【Oakforest-PACSは、米インテルの並列処理用プロセッサー「Xeon Phiプロセッサー」を搭載した富士通のサーバー機「PRIMERGY CX600 M1」を8208台使ったクラスターシステムである】

しかもIBMのPower7でもなければ従来の富士通のスパコンのSPARCでもなく PRIMERGYのインテルサーバw
AIXやSolarisじゃ悪いことできないからなw

東大の柏キャンパスではなく、白銀台の東京医科学研究所ではIBMのワトソンが「わずか10分で難症例患者の正しい病名を見抜く。医師に治療法を指南」。ネットなのでワトソンがどこのサーバーで稼働してるかなんて無意味な議論だけど。

ワトソン←ウィキ
「2011年1月13日にはトーマス・J・ワトソン研究所で…ワトソンは、10台のラックに搭載されたPower Systems 750で構成され、2880個のPOWER7プロセッサ・コアを搭載し、オペレーティングシステムはLinux」

2011年のワトソンは2880台のLinuxで稼働していた。で、柏の東大キャンパスに8208台のLinuxサーバが導入された。イスラム国™インスタンスを神戸の理研の「京」から柏に引っ越しするのか?

5月 10, 2016 東大と筑波大、「京」を凌ぐ国内最速スパコンを導入へ HPCwire Japan
東京大学情報基盤センターと筑波大学計算科学研究センターが共同運営する、最先端共同 HPC 基盤施設(JCAHPC:Joint Center for Advanced High Performance Computing、施設長:中村宏)は、2016 年 12 月 1 日に稼動を開始する共同利用スーパーコンピュータシステムとして、米国 Intel Corporation による次期メニーコア型プロセッサKnights Landingを採用した超並列クラスタ型計算機 Oakforest-PACSの導入を決定したと発表した。
同システムのピーク性能は「京」の10ペタフロップスを超え、25ペタフロップスを予定しており、国内最速のスーパーコンピュータとなる予定だ。
最先端共同 HPC基盤施設は、東京大学および筑波大学により共同運営されると共に、2大学が共同してスーパーコンピュータの調達・運用を行う、国内初の試みである。同システムは東京大学柏キャンパス内の情報基盤センターに設置されるが、システムの調達・導入・運用および主な利用プログラム運用などのすべてを2大学が共同で実施する。
新規導入される Oakforest-PACSシステムは、米国Intel Corporation による超高性能 メニーコア型プロセッサである次世代インテル®Xeon PhiTMプロセッサ(開発コード名: Knights Landing)と、同社による新型の相互結合ネットワークあるインテル® Omni-Path アーキテクチャを搭載した計算ノードを、8,208 台搭載した超並列クラスタ型スーパーコンピュータであり、同プロセッサを搭載した大規模システムとしては国内初となる。システム製作は富士通株式会社が行い、同社が HPC 専用に開発する次期PRIMERGYサーバが計算ノードとして採用される。さらに 26 PByte の並列ファイル システム、940 TByte の高速ファイルキャッシュシステム等(共に米国DataDirect Networks社製)が設置され、総ピーク演算性能として「京」コンピュータの約 2.2 倍の超高性能システムとなる予定だ。
新システムのピーク性能は 25 PFLOPS 以上、メモリ容量 900 TByte 以上です。全ノード及び並列ファイルシステムのサーバはインテル® Omni-Path ネットワークを Fat Tree 結合した、フルバイセクションバンド幅を提供する相互結合網で結合され、計算 ノードおよび共有ファイルシステムを柔軟かつ高効率で利用可能。さらに、SSD を搭載した高速ファイルキャッシュシステムにより、特に高いファイル入出力性能を求めるアプリケーションにも対応する。
本システムは2016 年12月1日から稼動を開始し、数カ月の実験的運用と特別プログラムによる利用を経て、2017年4月より HPCI を始めとする各種共同利用・共同研究プログラムに供される予定である。
なんだこの記事。検索エンジンに引っかからないように細工してあるし。

まさかブザンソンを調べててうちのBIOS更新テロの背景が判明するとは思わなんだわ。 しかも東大と筑波大のスパコンが設置された柏キャンパスには科警研がある。 これがD社(ケーサツ)とF社(PRIMERGY)をつないでたわけ。 しかも6月10日には糖蜜がニチギンのプライマリーディーラーを返上して独自のビットコインを発行とか言いだしてる。

あーぁ。不治痛解体されてるしw

投稿されたコメント:

コメント
コメントは無効になっています。