MSは自社の有料Webサービスの正常動作すら確認しない程度にはIEを見捨てているらしい。

 今回はビミョーな何だかなぁ感が残るお話。

 さて、当方が触る環境の中には所謂「管理された端末」というヤツがありまして。
 32bitのWin7にブラウザはIEだけ、Officeも2010のままバージョンアップの気配すら無し、というまぁ「日本企業では標準的」な端末でございます。
 そして当方、この端末を使ってMSのWebサービスを使うことがままあるのですな。

 なのだが、最近のMSはどうやら自社サービスがIEで正常に動くか全く確認していない模様。
 何故って、有料サービス含めて、FirefoxやChromeではまともに動くのにIEだとコケる、という事象が割と頻度高く発生しているんですよ。
 え、Edge?確認していないので不明。

 ちなみにコケてる理由はだいたい「IEにとって」DOMの扱いがミスってる、ということ。
 F12でデバッグコンソール見てみるとこんなのが出ていることが多い。

 >SEC7118: [URL] の XMLHttpRequest には Cross Origin Resource Sharing (CORS) が必要です。
 >SEC7119: [URL] の XMLHttpRequest には CORS プレフライトが必要です。

 はい、フツーにクロスドメインアクセス周りの不具合でございます。
 具体的な被害としては、ダイアログから先に進まない、ボタンが無反応、突然Access Deniedで蹴飛ばされる、ファイル転送が始まらない等。

 問題というか話がアレなのは、FirefoxやChromeで使っているとこのテの問題にはほぼ遭遇しないこと。
 究極的にはIEのバグというか互換性の話になるってことよね、コレ。
 そして、症状が出てから数日程度で、何事も無かったかのように直ったり、また突然発症したりを繰り返していること。
 特別な操作しなくとも簡単に再現可能な不具合が何度も繰り返し発症する辺り、まぁ少なくてもきちんとテストはして無いんだろうなと。

 あ、別にMSがIEを切り捨てることについては個人的には全く文句は無いんてすよ。というか、さっさと諦めてくれた方が幸せ。
 ただ、ならば明示的にアナウンスしてくれと。日本の「端末」管理者の大多数は未だにIEだけ動かしておけば安泰だと思考停止しているので、ね。

 とまぁ、本日はこんなしょうもない話でした、はい。

Share

突然だけど必要になったので。

3TB以下、7200rpm限定、非SMR限定、512でのLBAサイズを調べてみた。

—————-
東芝 DT01シリーズ(512e)
DT01ACA050 976,773,168
DT01ACA100 1,953,525,168
DT01ACA200 3,907,029,168
DT01ACA300 5,860,533,168

東芝 MD04シリーズ(512e)
全モデル非公開

東芝 MG04シリーズ(512e・512Native両方あり)
全モデル非公開

Seagate Barracudaシリーズ(512e)「Guaranteed Sectors」
ST500DM009 976,773,168
ST1000DM010 1,953,525,168
ST2000DM006 3,907,029,168
ST3000DM008 5,860,533,168

Seagate Barracuda Pro 「Guaranteed Sectors」
ST2000DM009 3,907,029,168 ※512B Native

Seagate IronWolf Pro 「Guaranteed Sectors」
ST2000NE0025 3,907,029,168 ※512B Native

WD・HGST(512e・512Native 両方あり)
全モデル非公開
—————-

こんな感じ。
にしても思ったより数字を出していないブツの多いこと。そしてLBA数がカッチリと固定されているのはこの中では一番の古参、DT01だけという有様・・・あひゃあ。

あ、Seagateは「保証セクタ数」であって、実ディスクのセクタ数が必ずコレとは保証していないのよね・・・まぁ実際は揃っている筈・・・だと思う・・・けど。多ければおトクという発想もあるかかも知れないが、用途によってはセクタ数って完全に揃っていないと困るんですよコレ。具体的にはRAID組む時、或いはRAIDのHDDが故障したので交換する時。
まぁそんなのデスクトップ用HDDで期待するなという言い方もとても正しいとは思うが、Seagateは5年保証のニアラインでも「保証セクタ数」でしか出していない・・・う~ん。

ちなみにWDとHGSTは非公開なので、ラベルに嘘書いていないレベルから逆算すると、最悪3TBは5,859,375,000セクタあれば嘘ではないことになる(3TB=3,000,000,000,000Byte計算で)。

P.S.
記憶が正しければ日立時代のHGSTはデータシートにセクタ数を乗せていたような。
というか、HGST傘下になってデータシート内容がどんどん削られている気が。

とまぁ、本日はここまで。

Share

米国デザインのVIA CPUが中国国産の看板を背負っていた話。

 本日のお題は先日見た「やじうまPC Watch」の記事から。

 その記事は「IDT WinChipの血統のVIA CPUは実は新製品が出ていました」というお話で、まぁそれだけならば「あ~」という程度で終わったのだが。
 ふと脳味噌の中で引っかかることがあったので、軽く調べてみたらあらまぁだったというお話。

 ♯当方はNehemiah(C3-1GHz)を自宅サーバにしていた時期もあります、はい。
  ちなみにM/BはAOpen製ののMX36LE-UN。当時は珍しい黒基盤がカッコ良かったんですよ。

 さて、本日何でこんな話を書いたかというと、以前「中国が国産のx86 CPUを開発した」的な話をどっかで見かけた記憶が残っていたので。
 実際問題としてx86 CPUを今更スクラッチで開発するなんてコスパ悪過ぎなのと、本当にスクラッチで開発していたらもっと大ニュースになっている筈なのにちっとも話題になってない→開発してね~な、ということで「まぁリブランドでもしてるんやろ」ぐらいに思っていたのだが。

 なので、記事に出てきた「兆芯」という会社は何じゃらほいと調べてみたところ。
 これ、英語名だとVIA Alliance Semiconductorという名前で、2013年4月に上海で設立されたJV(ジョイントベンチャー)。出資元は台湾VIAとShanghai Alliance Investment Ltd=上海SASAC=上海国務院国有資産監督管理委員会、要するに中国共産党ですわ。
 一方、米国側の関係会社というか母体というか踏み台になったのがVIA Alliance Technologyで、コレは遡ること2年半前、2010年9月に設立されている。

 そして現在、Centaur Technilogyは事実上VIA Alliance Technologyの傘下の模様。
 御存知だと思うので念のため、Centaur Technilogyはアメリカの会社です。

 ・・・ここまできて、もしやと思って「中国の国産x86 CPU」ネタを軽く調べたところ・・・ビンゴ。
 「兆芯から中国国産のx86 CPUが登場した」という文面が、中国語のサイトからガシガシ出てくるんですわ。

 ということで、以上から導き出される結論は。

 懐事情が厳しくなってきたVIAはCentaur Technilogyを「事実上」中国共産党国営企業に譲り渡した。
  ↓
 中国共産党国営企業は米国でデザインされたCPUをいつものノリで「国産x86 CPU」と言っている。

 という、まぁあるあるでしょうな。

 現在のVIAの主要ビジネスは組込向けマザーの供給だが、このビジネスの継続の為にx86の独自CPUを持っている必要性は正直無いし、それどころか自前で半導体チップを開発する必要すらない。実際、VIAのラインナップ見てみるともう半分以上はARM。

 一方で半導体チップの開発やサポートには正直コストがかかる。
 なのでVIAはそこそこ売れていたUSB Audio等も含めて自前のチップ開発を終了してしまった(結構あちこちから買い集めてラインナップ揃えたのにね)。
 ところが、CPUについては中国が欲しいといったので、JVを作って事実上譲り渡した、と。

 ♯恐らく開発費の大部分は中国が出してくれるだろうから、VIAからすると開発済CPUの供給継続と新規開発の成果を低コストで手に入れられる美味しい話だったのでは。

 ちなみにこの兆芯、割と最近35W/8C/2GHzというCPU「C-OctaCore FC-1080」を発表しているのだが、ベンチを見ると数字が何故か「2x VIA Quad Core 2GHz」という謎のボード(ちなみにチップセットはVX11)と誤差程度しか違わない。VIA Quad Coreの最新バージョンはMCMではなく1ダイになっていることと併せて考えると、何だか味わい深い感じですな。

 そしてこのベンチ結果、数字の絶対値を見るとPentium G3420(53W/2C/3.2GHz)とかCore i5-3230M(35W/2C/2.6GHz)と大差ない感じ。
 コア性能1/3かよ、というツッコミが入るだろうが、コアあたりの消費電力はノート向けIvyBridgeと比べても1/4なんですよ。

 つまり電力性能という見方をすると実は結構悪く無いのです、念のため。
 WinChipの伝統は脈々と受け継がれていますな・・・。

Share

TractionはBananaがお好みだったらしい。

 タイトルが何だかなぁだが、今回はまたしてもDAWを使ってVSTをPC音声出力に突っ込むという話。
 また問題が出てしまったので、その話でも。

 ◇

 前回ネタにしたように、VSTHostではなくTracktion5を使うことで音が遅延してどんどんズレていく問題は解消したのだが。
 しばらく使っていると、今度は別の問題が発覚したんですな。

 それは、MME(Windows Audio)を使うと、割と頻繁に音飛びするということ。

 そりゃMMEなんて使うからだろというツッコミはある意味正しく、DirectSoundを使えば音飛びの頻度は減らせるものの、ゼロにはならない。
 しかもDirectSoundを使うとKernel Mixerの影響をモロに受けてしまうという。MMEの方が小手先テクニックで影響を減らせるようなので、敢えてMMEを使っていたのですよ。
 勿論、MPC-HCではWASAPI出力が使えるのでこれを使っているが、それをVB-Cableに通してしまうとTracktionはMMEかDirectXでしか入力出来ない。
 まぁこれも環境依存らしく、環境によってはあまり気にならないが、一方で1分も間があかずに音飛びまくる環境も。

 それでは原因の切り分け・・・ということで、折角のDAWなので入力側を録音してみたところ、録音の段階で音飛びしていることが判明。これつまり、TracktionがMME経由での録音はあまり得意でないってことなのか、単にVB-Cableとの相性なのか。ASIO入力だとこんなこと起こらないんだが。

 ♯勿論音源になるソフトから直にハードウェアに音声出力すれば音は飛ばないですよ。

 まぁこうなると、結論としては「TracktionはASIOで入出力」しかない、ということですな。

 勿論ハードウェアループバック使えば簡単に出来ますよ。おカネかかるけど。
 それではソフトウェアだけで出来るかな、ということで、色々探してみたのだが、結論としては

 「タダでは無理、DonationWareを使えば出来る」

 ということで。以下、具体的な手法。

 使用するDonationWareはVB-AudioのVoicemeeter Banana。
 これはソフトウェア仮想ミキサーだが、全ての仮想I/OにMME・DirectX・KernelStreaming・WaveRT・ASIOが使えるという変態的、違った、汎用性の非常に高い構成なのですよ。
 なので、以下のように繋げればTracktionをASIOで使えるばかりか、KernelMixerも完全排除出来るという。

 MPC-HCからWASAPI出力
 →VoiceMeeter BananaからASIO出力
 →Tracktion5からASIO出力
 →Voicemeeter BananaからASIOまたはKernelStreamingで出力

 実際にこのソフトを使うとケーブルが無いので(当たり前だ)何処がどう繋がっているかやや分かり難いものの、一度ルーティングを理解してしまえば何の問題も無い。

 そして音は・・・おお、飛ばない!
 ASIOバッファを詰め過ぎれば当然音は飛ぶが、逆に言うとそれ以外では音飛びは出てこない。

 まぁ短時間の確認なんでウン時間も流し続ければもしかしらたまに飛ぶのかも知れないが、少なくともMMEやDirectSound使っていたら間違いなく飛びが確認出来るだけの時間はかけたので、これは間違いなく改善している。

 ◇

 ということで、問題を解決したものの、それには結局追加投資が必要だということに。
 DonationWareってことは要するに試用期限が切られていないシェアウェアなんで、使い続けるなら送金しないと。
 ん~、背に腹は代えられないってヤツなのかなこれは。

 以上、今回はここまで。

Share

XTS-AESが漸く使えるようになったのでBitLockerについておさらいしてみた。

 さて、本日はBitLockerのお話でも。

 Windows10 1511では結構あちこちに手が入っているのは周知の事実。
 その中でも、個人的にはかなりの注目ポイントだと思われるのに、世間では全く取り上げられていないネタが一つ。

 「Windows10 1511からBitLockerでXTS-AESがサポートされた」

 漸くというか何で最初から無かったのといか、そういうレベルではあるが。

 これでBitLockerも漸く「世間並の暗号化強度」と胸を張って言えるようになりました・・・のだが。
 これが世間で全く注目されないということは、やっぱりストレージ暗号化なんて世間では全く流行っていないってことよね、コレ。

 一方で、従来Windows8から使われてきたAES-CBCについて、何だか微妙に誤解されているような雰囲気も。

 ということで、今回はBitLockerの歴史と暗号強度の話でもしてようかと。

 ◆

 まず、暗号化ってのは当然ながら強度が高い方がいい。
 但し実際には互換性や処理能力からどこかで「妥協」が発生するので、実際にはこの「妥協」点が適切か、という話になるのですよ。

 ◇

 ということで、まずは初代BitLockerから。
 いわゆるNT6カーネル→Windows Vista~7、2008~2008R2にて実装。

 暗号化モードはAES-CBCで128bit(こちらが標準)または256bit、更にElephant Diffuserが標準で付いてくるが、使用しない設定も可能。

 最大の特徴はElephant Diffuserという難読化(というか掻き混ぜというか)アルゴリズムを使っていることで、AES-CBCにおける攻撃耐性の弱さをこれでカバーしている。
 一方で欠点もElephant Diffuserに存在し、何しろコレはAESのような標準化された手法ではないのでハードウェアアクセラレーションが効かず、結果としてBitLockerの重さの主原因となってしまったと言われている。

 ちなみにこの初代BitLockerの詳細についてはMITのサイトに公開されているMSの論文(https://css.csail.mit.edu/6.858/2013/readings/bitlocker.pdf)にかなり詳しく書かれているので興味ある方は一読を。

 ◇

 次は2代目BitLockerから。
 いわゆるNT6.1カーネル→Windows 8~8.1、2012~2008R2にて実装。

 暗号化モードはAES-CBCで128bit(こちらが標準)または256bitのみ。
 恐らく速度を優先するために、Elephant Diffuserのサポートをしれっと切ってしまったというのが最大のポイント。標準として使用しないとしても選択肢として残すぐらいしておけば良かったのに、サポート切りってどうよ、と。

 さてそれではAES-CBCの何がそんなにマズいのか。

 先程も「攻撃耐性の弱さ」と書いたが、「特定の状況」では簡単に突破して解読出来てしまうのですよ、AES-CBCって。
 しかもこの「特定の状況」、攻撃者は暗号化キーを知る必要が無いという。

 これだけ訊くと「それじゃ暗号の意味ないじゃん」という方、ちょっと待った。
 この「特定の状況」って、攻撃者は暗号化キーこそ知る必要はないものの、それ以外の状況は結構特殊なんですよ。

 その特殊な状況というのは、攻撃者は暗号化キーは知らないが、最低限復号されたデータにはアクセス可能、というもの。
 個人ベースで一つの環境を占有していればこういう状況には遭遇しようがないが、一方でエンタープライズ系で集中鍵管理やっていたり、家族みんなで同じ環境使ってますなんて環境だと想定しうる事態なんですな。
 そのような状況では、例えば権限管理が甘いor突破されてしまうと、本来読めてはいけない筈のデータが読めたり書き換えできてしまったりする可能性があるんですわ。

 これがAES-CBCの攻撃耐性の弱さなんですな。
 エンタープライズでは複数のユーザーが権限を使い分けるなんて当たり前なので、こんな調子じゃとても許容し辛い。
 なので実際に(ディスクの暗号化が必要な)大多数の企業では、サードパーティ製でXTS-AES等の強度の高い暗号化が出来る専用ツールが導入されていたりするんですな。

 逆に言えば、個人が自分専用で使うUSBメモリのようなメディアなら、AES-CBCでも事実上十分な暗号化強度を持っていまっせ。そういう使い方ならアルゴリズムよりもキーの方の強度を心配しましょう、はい。

 ♯いくらAESが突破不能でも、辞書攻撃や総当たり攻撃で暗号化キーがあっさりヒットするようでは元も子もない。

 ◇

 そして3代目BitLocker。
 実装はWindows10 1511以降。WindowsServer 2016でも標準サポートしていると思われるが未確認。

 最大の特徴はXTS-AESを採用したこと。
 IEEEで標準化された暗号化アルゴリズムを採用することで、最近のCPUが備えるハードウェアアクセラレーションを活用してElephant Diffuser以上の難読化を高速に処理することが可能となった上、FIPS等の他の規格にも準拠し易くなったという良いことづくめ。
 勿論、エンタープライズの世界でも使い物になる。

 欠点はというと単純に昔の環境では見えないということぐらい。

 ちなみにWindows10 1511以降でしか使用しない前提ならば、XTS-AESを使用した方がAES-CBCより処理速度が速い上、強度も高いので選択しない理由は無い。
 ついでに言うとデフォルトはAES128のままだが、ハードウェアアクセラレーションが効いている環境ならAES256にしても誤差程度しか処理速度に差が出ないので、そちらに変更することをおススメ。

 ◆

 最後に、実際の設定方法。ポリシーで設定すること可能だが、個人的にはレジストリで。

 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE

 EncryptionMethodWithXtsFdv [DWORD] ←固定ドライブ
 EncryptionMethodWithXtsOS [DWORD] ←OS起動ドライブ
 EncryptionMethodWithXtsRdv [DWORD] ←リムーバブルドライブ

 1 →AES-CBC 128 /w Elephant Diffuser (Vista/7 Only)
 2 →AES-CBC 256 /w Elephant Diffuser (Vista/7 Only)
 3 →AES-CBC 128
 4 →AES-CBC 256
 5 →XTS-AES 128 (W10 1511~)
 5 →XTS-AES 256 (W10 1511~)

 ということになっております。
 ちなみにポリシーで設定する場合の場所はここ。

 グループポリシーエディタ(gpedit.msc)起動
 コンピューターの構成→管理用テンプレート→Windowsコンポーネント→BitLockerドライブ暗号化

 ・ドライブの暗号化方法と暗号強度を選択する(Windows8、Windows Server2012、Windows8.1、Windows Server2012 R2、Windows 10 [Version 1507])
 ・ドライブの暗号化方法と暗号強度を選択してください(Windows 10 [Version 1511] 以降)
 ・ドライブの暗号化方法と暗号強度を選択する(Windows Vista、Windows Server2008、Windows7、Windows Server2008 R2)

 ・・・この翻訳の揺れは何。

 ◆

 以上、本日はこんな感じで。

Share