カテゴリー: Software

Windows10 UpgradeするとDiskが見えなくなる件について。

Posted on by S.Kaz

　さて、そろそろWindows10 1607（Anniversary Update）についてもサポートが切られるようで。
　忙しいなぁとは思いつつ、基本タダでアップグレードしているんでまぁアリっちゃアリか、というのが当方の感想なのですよ。

　なのだ、が。
　手元にある1607の環境（メインPC！）が、どう頑張ってもUpgrade出来ないという事態に嵌ってしまっているんですな。

　で・・・例の「Upgrade Assistant」がデスクトップに出現してからも、初期の頃はそもそも「インストール完了」まで辿り着かなかったのでエラーが出る度放っておいたのだが。
　先月ついに普通のWindows Updateまで挙動がおかしくなってきたので、キャッシュの削除やらchkdskやらdismやsfcやら特定KBの手導入やらと色々「フルセット」をやったところ、Windows Update自体が正常に完了すると共に「インストール完了、再起動します」まで無事辿り着くように。

　なのだ、が。
　これで再起動すると見えるのは「キーボードレイアウトの選択」画面。
　そう、フツーに回復環境に落ちちゃうんですよ。
　で、ここで何も出来ないので、諦めてリブートすると、Upgrade前のWindows 10に戻れるという。

　♯これでもこの状態で（USB接続の）マウスとキーボードが動くだけFall Creators Updateはマシで、Anniversary Updateの回復環境だとこのマシンだとマウスもキーボードも動かずこの時点で積みます、えぇ。これって、地味に回復環境もドライバの互換性とか改善しているってことかな？

　で・・・最初の1回は「まぁどっか不具合あったのかな」だったが、その後何度やっても全く同じ状況で進歩せず。そのうち「今すぐUpgradeしろ」の表示がどんどんしつこい＆ウザい感じになってきて「いやこっちだってアップグレードしたいのにさせないのあんただろ」的なUpgrade→失敗を何度か繰り返し。
　いい加減付き合うのに疲れてきたんですな。

　で、一体何が起こっているんだ・・・と回復環境でコマンドプロンプト起動してみたところ。

　「あの、プライマリディスクが見えませんが」

　Adaptec配下のWindows10の入ったHDDが見えていないんですわ。AHCI配下の作業場ディスク（非RAID）しか見えてない。
　つまりこれ、起動時にLegacy Adaptec用のドライバが読み込まれていない。これじゃ起動出来るワケがない。

　・・・そこですか。
　Fall Creators UpdateではLegacy Adaptecドライバが入っていないのか？って、既に手元にある他のFall Creators Update当たってる環境見てもドライバ入っているし、バージョンも同じやん。
　つまりこれ、Updaterのバグだよね。必要なドライバを導入しないという。
　ディスクドライバを直指定して無理矢理読み込ませる方法とか、リブート直前に何か仕込むとか、何か回避法ないんかこれ。

　ということで、未だにFall Creators Updateが当たっていない当方のメインPC。
　いい加減パッチ来なくなるし、さてどうしたものか・・・。

　♯にしても、普段特に何もしていないつもりなのに、ふと思い出してチェックしてみるとsfcではエラー出ないのにdismで修正が走ること多いなぁ。これウチの環境固有の問題・・・ではないと思うんだけどねぇ。

Share

Intelの意地汚さがここまで露骨に出るとは、「Meltdown」はIntelにとって余程ヤバいものらしい。

Posted on by S.Kaz

　新年あけまして・・いきなり「Spectre」「Meltdown」脆弱性ネタで大騒ぎから始まったPC業界。何だかなぁ。

　いやね、Intelがアレなのは事実なのだが、普段なら「見掛けは」スマートに済ませるんですよ。実体は兎も角として。
　ところが今回は今まで見たことない程余りにも露骨に「オレだけじゃない」「(パッチ当てても)そんなに遅くならない」と言い訳しまくっているワケで。海外の辛口系メディアには早速ネタにされまくっているが、そこまで言い続けるということは実際には余程ヤバいんだろうなぁ～、と。

　♯日本のPC業界は何故か病的にIntel信者が多いのでね・・・海外と日本のこの情報密度の違いよ。
　　あ、ちなみに。少し前のEPYCをボロクソに言ってるスライドも（当時は）前代未聞・異例且つ中身がほぼ中傷というアレさで海外のtech系サイトの一部ではネタとして話題になったが、結局広がらなかったわね・・・中身が重箱の隅過ぎでしょアレ。

　ただでさえ、昨年末には「10nmプロセスが全然アカンのです」と自ら告白したも同然の14nmプロセスCPUコードネームの追加があったばかり。以前ネタにしたように、湯水のように現ナマを流し込むことで最先端プロセスをいち早く安定させてきたIntelをして、10nmが安定しないというのは・・・いよいよ「微細化の限界」ってヤツですな。

　あ、一部に「コストが合わないだけだ」という言い方をする人が居るんですが、半導体製造プロセスをある程度知っている人間から見ると「コストが合わない」＝「プロセス開発失敗」なワケですよ。
　何故って、半導体の製造プロセスを設計する場合、一定の期間に一定のイールド（算出率・良品率）が取れることを前提にコスト構造を組み立てて「元が取れる」世界観を組み立てるんですわ。なのに「コストが合わない」＝「生産した製品が想定した品質に届かない」＝「作っても損しかしない」って、これ世間では「失敗」と言いますわね。
　で、Intelの場合は今まで製品をクソ高く売ることが出来たので、原価も他のファウンダリ（「ファウン『ド』リ」表記の方が一般的らしい）と比べて高く設定出来たワケですよ。そのIntelをして10nmが量産開始出来ないというのだから・・・どんだけハードル高いんだよと。

　♯この「元が取れる」とこが見えなくてプロセス開発中止、なんてこと自体は最近では世界中のファウンダリでそう珍しいことではないんですが、昔は結構珍しかった。このこと自体開発コストが上がっていることの一つの証明ですな。

　まぁそんなこんなでIntelにとっては波乱の幕開けとなった今年。
　AMDやARMにとっては棚ぼたなのだが、皆様御存知の通りこういうチャンスをロクに活かせないのがAMDという会社だし、ARMはさすがに棚ぼたを受け止められるだけの器が未だ無い状態なので、結局Intelの絶対王政が変わることもないんでしょうな、としか。

　♯自分はAMD派だが、AMDの商売センスの無さは伝統芸だということはきちっと認識してまっせ、えぇ。

　まぁ取り敢えず、現時点で技術的な脆弱性そのものの情報はほぼ出てきているように見えるので、後は影響範囲がどこまで広がるか観察してみましょうか、というとこですな。
　現時点の情報だと、クライアントPC系OSやアプリのようにパッチ当て易い範囲では影響は収まっていなさそうだし。

　もう一つ、これからパッチが全世界にバラ撒かれるそうなので各所から悲鳴が上がってくる様子も見てみることにしましょう。
　Linuxカーネルにパッチ当てるとWorkloadによってはパフォーマンス3割ダウンとか相当酷いことになるらしいし、既にAmazonではパッチ済みLinuxが稼働していてパッチ以前に比べてCPU負荷がガン上がりしてるとAWSの中の人が言っているし。

　あと・・・これ集団訴訟来るかね？
　主要な影響はサーバーと言いつつコンシューマーに影響が皆無というワケではない筈なので、その辺りを考えるとあの訴訟大国ならやりかねんな、と。

　とまぁこんな感じで、本日はここまで。

Share

久しぶりに使ってみたらLibreOfficeがだいぶ軽くなっていたという話、或いは現在のLibreoffice Darwが結構イケてるという話。

Posted on by S.Kaz

　本日は・・・ってタイトルがまんまはあらすじです、はい。

　◇

　さて、会社で事務仕事をするPCであれば世間では大体Officeが入っていると思われる（バージョンは兎も角として）のだが、それでは自宅でPCは？と。
　まぁ日本ではメーカー製というか「Pre-Installed Softwareてんこ盛り」PCの割合が高いので、特に意識しなくても（バージョンとかサポート期間は兎も角として）正規ライセンスのMS純正Officeを使っている割合が高いらしい。

　ところで、自分は御存知の通り自作PC使い。当然Pre-Installed Softwareなんて無いし、一部の店舗で扱っているBundle版ライセンスも自分のようにパーツ交換を「思い立ったが吉日」でやっているような人間には非常に使いにくい。ライセンスの引っ越し・移行について分かり難いだけでなく、海賊版対策でシステム認証が煩雑になっていたり、昔は許容されていた手法が新しいライセンス契約で禁止になってしまったりしていて、価格が安い以上のデメリットが。

　結果どういうことになっているかというと、通常パッケージ版を導入しつつも、結局は複数台あるPCの一部にしかOfficeが入っていないという環境が出来上がっているのが現在なんですな、えぇ。だってほら、Officeって安くないし。
　まぁ複数台のPCでそれぞれ環境の方向性が違うので、Officeを使う必要があれば特定のPCを使う、ということで現在のところは特に問題にはなっていない。

　え、そこまでしてOfficeを買う必要があるのか、って？
　いやね、Office本体、というかWord・Excel・PowerPoint（と要らないけどOutlook、使ってないけどOneNote）についてはある意味必須なんですよ、今の自分の立ち位置ではね。ぶっちゃけ機能面で「Office互換製品」で不足するような使い方をしているとは思わないが、問題になるのはファイルの互換性。特に印刷する時に体裁が崩れるのは致命的（これは自分の立ち位置故の特性）なので、こうなると現時点では「互換ソフト」を使うのは難しいんですわ。
　まぁそういう理由で手元にOfficeがあれば、個人的な、ファイルの互換性がどうのこうのと言われる必要のない場面でもこれらのMS純正Officeを使うことになる訳で、それに機能面では特に不満も不具合も無かったワケですよ。お値段は兎も角として。

　・・・が、ここで問題が。Visioですよ。

　使っている人からすると必須ツールに近い、使わない人からすると存在価値不明というぐらい「認識格差」のあるOfficeファミリーのSoftware。元々は別会社の製品（MSが開発販売元の会社ごと買収）だったので今でもUIや操作体系が今でも他のWordやExcelとは一味違うのだが、自分は前者ですな、はい。
　なのだがこのVisio、単純に言って「高い」んですわ。Standard版でもOfficeのHome＆Business版より高く、Professional版に至ってはAccessまで「全部入り」のOffice Professionalよりも高いという、完全に足元を見た値段という。

　勿論、会社の仕事では会社のカネで買ったVisioを使っていまっせ。当然会社の端末にインストールされていて、会社のライセンス管理の下にある。だが、これをプライベートで使う為にポケットマネーが買うかと言われると・・・いやぁ、高過ぎでしょ。

　一方で、最近プライベートでもちょっとした図面を描いておきたいというイベントが立て続けに発生したんですわ。内容的にはVisioで描くのが実にぴったりなモノなのだが、手元にVisioは無い。簡易CADのような「図面」としたいので、PowerPointで描くには面倒過ぎる。描いた内容はpdfにさえ出来れば最悪どうにかなる。さてどうする。

　◇

　・・・いやぁ長い前振りでしたな。

　そう、ここで思い出したのがLibreOffice。昔使ったLibreOffice DrawがそういえばVisioっぽいモノだったと。
　但し記憶の中のLibraOffice Drawはお世辞にも「使えたものじゃない」という代物。クソ重いし、日本語の表示が欠けるし、全体的に挙動がヘンというか怪しいし。だがその頃のLibreOfficeはLibreOfficeという名前になったばかりのバージョン3.3。現在は5.3。もう一度試してみるか、と。

　とまぁこんな流れがあって、もの凄く久しぶりにLibreOfficeをインストールして、Drawを起動してみたところ。
　・・・あれ、フツーに使えるんですが。
　確かに細かいところを見ると、位置取りをセンチ単位にすると誤差っぽい数字が出るとか、複数の線を繋ぐと微妙にズレが出る（多分前述のネタと同じ原因だと思う）、文字の場所指定がきちっと出来ない、ざっと見でこの3点は気になるものの、それ以外はかなりイイ感じですよ。
　レスポンスも悪くないし、何より、補助線やメニューの出し方の「気の利き方」が物凄く良くなっている。

　この時ふと思い出したのが、（会社の）Visioを2010から2016に一気にアップデートした後の印象。2013は（会社が買ってくれなかったので）良く知らないのだが、2010と2016を比べると「一皮剥けた」という表現がぴったり来るぐらい体感が違ったのであり。もうその瞬間に「2010は無いわ～」と言いたくなるぐらいには。
　それでは具体的にどう違うのかと言われると、「気が利くようになった」という実にアレな表現しか出来ないのは当方の語彙の無さそのものなのだが、LibreOffice 5.3のDrawの機能と「気の利き方」は、自分的な使い方ではVisio2016にも引けを取らず、2010と比べたら確実にDrawの方が上。

　勿論、Visioを純粋に図面描きにだけに使っているというのはMSに言わせれば「機能の一部しか使っていない」ということになるのだろうが、自分の使い方だと「PowerPointでは手に余る図面を描く簡易CAD」以上のものは正直求めていないワケで。

　◇

　まぁそんなワケで、それ以来当方はLibreOffice Drawを普段から使うことになりました、と。
　本日は以上です、はい。

Share

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

Posted on by S.Kaz

　タイトルが何だかなぁだが、今回はまたしても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についておさらいしてみた。

Posted on by S.Kaz

　さて、本日は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