・CSSをハックしてパスワードを盗み取るキーロガーが登場 - GIGAZINE
GitHub - maxchehab/CSS-Keylogging: Chrome extension and Express server that exploits keylogging abilities of CSS.
https://github.com/maxchehab/CSS-Keylogging
How to Uninstall XXXXX
So to uninstall XXXXX from Windows 10, make sure that you are using the old add/remove UI.
To ensure that you are, follow these steps:
- Use WinKey+R to open the “Run dialog”
- Type: control appwiz.cpl
- Press “OK”
- Scroll down to the “XXXXX” entry and double click it
参考
・How to Uninstall Vivaldi (Windows 10) | Vivaldi Browser Help
Firefox: AppCacheへのHTTPアクセスを遮断
Webアプリケーションをオフラインでも動作するようにするには、ローカルにデータをキャッシュする必要がある。“AppCache”はそのためのキャッシュメカニズムを提供しているが、現状ではHTTP接続からでもHTTPS接続からでもアクセスが可能だ。
しかし、暗号化により通信が保護されていないHTTP接続には、“なりすまし”の可能性が排除できない。また、“AppCache”にはキャッシュを再検証しないようにできてしまう問題があり、改竄されたデータが一旦HTTP接続経由でキャッシュに書き込まれてしまうと、不正なデータがずっと使われ続けてしまう恐れがある。“AppCache”へのアクセスを保護されたHTTPS接続のみに限定してしまえば、こうした問題を解決することができる。
ソ－ス：Mozilla、アプリキャッシュへのHTTPアクセスを遮断 ～「Firefox 62」から正式導入へ - 窓の杜
「Firefox 60」以降の“Nightly”版とベータ版でテストされたのち、「Firefox 62」からは正式版にも導入される。
ubuntu: Spectre/Meltdown対策，さらにその後
業界全体を巻き込んだ混乱になっているSpectre/Meltdown対策について，Ubuntuでも新しい動きがありました。いくつかの面で問題のあった既存の更新（Intelの更新版マイクロコードとあわせて動作する幾つかの修正）を破棄して，Retpolineベースの対策に切り替える大規模修正がマージされています。
テストが行われた後，カーネルパッケージとして入手可能になると見られます。既存のIBRSベースの緩和策とは異なりマイクロコードの更新とペアで動作するわけではないので，カーネルパッケージ単体での更新で対処できます。
なおRetpolineによる防御も常に有効なわけではないため（一定条件下で防御しきれないケースがLKMLで指摘されています），さらにもう一段階，必要に応じてIBRSを利用する，といったアプローチの試行錯誤が行われています。今後，より新しいパッチセットをベースにしたカーネルが投入される可能性があります。
ソ－ス：2018年2月9日号 JRE/JDKの変更，Spectre/Meltdown対策さらにその後：Ubuntu Weekly Topics｜gihyo.jp … 技術評論社
関連：
・グーグル、「Spectre」フィックスによる性能への影響はほぼ無いと強調 - ZDNet Japan
・GoogleはSpectreとMeltdownの対策を昨年6月に開始し12月には完了していた。性能低下の報告はなし － Publickey
Google ドライブ：Office文書に直接コメントを追加できる
プレビューモードで「Microsoft Office」ドキュメントやPDFファイル、画像ファイルにもコメントを付けられるようにしたことを明らかにした。わざわざ“Google ドキュメント”の形式へ変換しなくても、元のファイル形式に直接コメントを付けて意見をやり取りできるようになる。
Win10のネットワークプロファイルをPowerShellで変更
Windows PowerShellを管理者として開き、
Set-NetConnectionProfile -Name "ネットワーク名" -NetworkCategory Private|Public
確認
Get-NetConnectionProfile -Name "ネットワーク名"
「ネットワークプロファイル」が表示されないので。
関連：
・Windows 10でますます迷宮化する“ネットワークの場所の切り替え”――どうしたら簡単に操作できる？：その知識、ホントに正しい？ Windowsにまつわる都市伝説（40） - ＠IT
ext4のパーティションをWindowsで読み書きする方法
Fx58.0.1 user.js
// Firefox 58
// 機能停止
user_pref("reader.parse-on-load.enabled", false); // リーダーモードを無効
// セキュリティ
user_pref("browser.urlbar.trimURLs", false); // 「http://」,「https://」を表示
user_pref("geo.enabled", false); // 位置情報通知機能を無効にする
user_pref("network.IDN_show_punycode", true); // 「homograph attack(ホモグラフ攻撃)」を進化させた手法対策
// 操作
user_pref("browser.tabs.closeWindowWithLastTab", false); // 最後のタブを閉じたときに終了しない
user_pref("browser.backspace_action", 2); // ［Backspace］キーで戻る機能を廃止(Windowsのみ)
user_pref("view_source.tab", false); // ソ－スをwindow表示
BIOSとマイクロコード
■BIOSとマイクロコード
本稿執筆時に使っているマザーボードはAsustekのP4B533-Eです。845E(Brookdale-E)チップセットの古いマザーです。最初に使ったCPUはCeleron1.7GHz(FSB:400MHz, S-Spec:失念, Wilametteコア)で、1年後にCeleron2.4GHz(FSB:400MHz, S-Spec:SL6XG(C1-Stepping), Northwoodコア)に交換し、これからPentium4-3.06GHz(FSB:533MHz, S-Spec:SL6PG(D1-Stepping), Northwoodコア)に交換します。
ASUSのWebサイトを調べると、1011以降のBIOSであればPentium4-3.06GHzに対応していることになっています。今入っているBIOSは1014なので、対応していることになります。でも1014のリリース日は2003年3月になっており、果たしてD1ステッピングのPentium4-3.06GHzに対応しているのかどうかはWebサイトを調べただけではわかりません。
本題に入る前に、CPUのステッピングとBIOSの対応を調べることがなぜ大事なのかを説明します。かつて初期のPentium(60MHz/66MHz/90MHz/100MHz)が、FPU命令のバグ(FDIV, FPREM, FPTAN, FPATAN)でリコール(交換・回収)されたことがありました。新聞で大々的に報じられ、IBMなどの大手メーカーが搭載機の出荷を自粛するなど大騒ぎになりました。(インテルが「トラブルに遭遇する確率は数千年に一回であり、実使用上まったく問題ない」と発表しているにもかかわらず出荷停止措置になるのを見ていて、メーカー側がトラブルに便乗してインテルをいじめているかのような印象を持ちました。)その後、インテルはこれに懲りたのか、CPUのマイクロコードにパッチを当てる仕組みを開発し、PentiumIIの頃から実装しています。(「PentiumIIの頃」という曖昧な表現になっているのは、どの製品から導入したのかが正確にはわからないためです。MMX Pentiumの頃からあるのかもしれません。)
以前「日経バイト」で読んだ記事によると、マイクロコードにパッチを当てる仕組みは、
- BIOS内部にパッチを保持
- CPU起動時にステッピングを読み取り、対応したパッチをCPUへ転送
- パッチそのものは暗号化されている
のようなものだそうです。(この記事を失念してしまった。残念。)パッチがステッピング毎に用意されているのは、CPUのバグはステッピング毎に管理されているからです。エラッタについては、インテルが発行しているエラッタ集に記載されています。(CPUのエラッタが公開されるようになったのはPentiumのFDIVバグ騒動のもたらしてくれた思いがけない(いい)副産物だと思います。これ以前、エラッタ情報はエンドユーザーには非公開でしたから。)
BIOS内部でステッピングを読み取り、パッチを当てているので、CPUとBIOSの対応を調べることが重要になってくるわけです。なおインテル製CPUのステッピングは、Processor Spec Finderで調べられます。
■BIOSを調べる
P4B533-EのBIOSはAward製なので、AwardのBIOSを編集・閲覧できるツールが必要になります。以前はAward社のWebサイトで配布されていたらしいですが、その後中止されたらしく、検索して探し出す必要があります。有名なのはCBROMで、オープンソースのものとしてAwardModがあります。もっと検索していたところ、うるりの物置きで‘MicrocodeViewerを見つけたのでこれを使うことにします。
Pentium4-3.06GHzに対応した最初のBIOSである1011を調べてみます。
【P4B533-E用BIOS(1011)の対応CPU】 << C:¥BIOS¥1011E.awd >> < 1011E.awd/cpucode.exe > 2002/01/11 Rev. 0x12 (CPUID 0xF0A) ? PGA-603 Pentium 4 Xeon Processor 2002/01/12 Rev. 0x28 (CPUID 0xF12) SECC Unknown CPU 2002/02/11 Rev. 0x03 (CPUID 0xF13) SECC Unknown CPU 2001/05/29 Rev. 0x01 (CPUID 0xF21) SECC Unknown CPU 2001/07/30 Rev. 0x08 (CPUID 0xF23) SECC Unknown CPU 2002/01/14 Rev. 0x0B (CPUID 0xF24) SECC Unknown CPU 2002/06/28 Rev. 0x24 (CPUID 0xF27) SECC Unknown CPU
こりゃ、駄目です。D1-Stepping(CPUIDは0xF29)用のパッチが入っていません。次に今入っている1014を調べてみます。
【P4B533-E用BIOS(1014)の対応CPU】 << C:¥BIOS¥1014e.bin >> < 1014e.bin/cpucode.exe > 2002/07/16 Rev. 0x14 (CPUID 0xF0A) ? PGA-603 Pentium 4 Xeon Processor 2002/07/16 Rev. 0x2C (CPUID 0xF12) SECC Unknown CPU 2002/07/17 Rev. 0x04 (CPUID 0xF13) SECC Unknown CPU 2001/05/29 Rev. 0x01 (CPUID 0xF21) SECC Unknown CPU 2001/07/30 Rev. 0x08 (CPUID 0xF23) SECC Unknown CPU 2002/07/19 Rev. 0x0F (CPUID 0xF24) SECC Unknown CPU 2002/11/06 Rev. 0x33 (CPUID 0xF27) SECC Unknown CPU 2002/11/11 Rev. 0x0A (CPUID 0xF29) SECC Unknown CPU
CPUIDが0xF29用のパッチが入っています。ついでにベータ版のBIOS(1015.003)を調べます。このBIOSはD1-Stepping以降しか存在していないCeleron2.8GHz(FSB:400MHz, Northwoodコア, Socket478)に対応しています。
【P4B533-E用BIOS(1015.003)の対応CPU】 << C:¥BIOS¥1015003.bin >> < 1015003.bin/cpucode.exe > 2002/07/16 Rev. 0x14 (CPUID 0xF0A) ? PGA-603 Pentium 4 Xeon Processor 2002/07/16 Rev. 0x2C (CPUID 0xF12) SECC Unknown CPU 2002/07/17 Rev. 0x04 (CPUID 0xF13) SECC Unknown CPU 2001/05/29 Rev. 0x01 (CPUID 0xF21) SECC Unknown CPU 2001/07/30 Rev. 0x08 (CPUID 0xF23) SECC Unknown CPU 2002/11/07 Rev. 0x18 (CPUID 0xF24) SECC Unknown CPU 2002/11/06 Rev. 0x33 (CPUID 0xF27) SECC Unknown CPU 2003/04/14 Rev. 0x11 (CPUID 0xF29) SECC Unknown CPU
1014よりも新しいRevisionのパッチが入っています。BIOSをアップデートして1015.003に入れ替えようかと考えましたが、
などの理由から、1014のままで使い続けることにしました。
CPUを交換して電源を入れたところ、以下のような画面が表示され、正常に認識されました。Hyper Threading対応のCPUなので、CPU2の表示が出るようになっています。
起動時画面 Award Medallion BIOS v6.0, An Energy Star Ally Copyright (C) 1984-2002, Award Software, Inc. ASUS P4B533-E ACPI BIOS Revision 1014 CPU1:*Intel(R) Pentium(R) 4 3066 MHz Processor CPU2: Intel(R) Pentium(R) 4 3066 MHz Processor Memory Test : 1048576K OK
AwardのBIOSであっても最近のものや、AMIなど他社のBIOSでも上記のようにして調べられるのかどうかはわかりません。
■マイクロコードにパッチをあてる手順
BIOSが持っているCPUID:0F29h用マイクロコードのパッチのRevisionは、0x0Aですが、Windows XP SP2上でwcpuid, CrystalCPUIDを使って調べると0x21になっています。Windowsがパッチをあてているのだろうかと考えて調べてみたところ、マイクロコードにパッチをあてる方法が、インテルが発行しているIA32ソフトウェア・デベロッパーズ・マニュアルの「システム・プログラミング・ガイド」に書いてありました。(手元の版だと、「第8章：プロセッサの管理と初期化」の「8.11 マイクロコード・アップデート機能」)概要はこんな感じです。
- アップデート用のデータのヘッダーは48バイト
- アップデート用のデータは暗号化されており、サイズは2000バイトもしくは4バイト単位のサイズ
- CPUはリアルモード・プロテクトモードのどちらでもよい
- パッチデータは現在のCPUモードでアクセスできるアドレス空間内のどこに配置してもよい
- リアルモードでパッチをあてる場合はセグメント境界をまたがないようにパッチデータを配置する
- EDX:EAXにパッチデータのアドレスを入れ, ECXでMSRを指定した上で、WRMSRを使って書き込む
- Pentium4の場合、MSRは0x79となる(ECX=79h)
■Linuxでの実例
さらにLinuxのカーネル(2.6.8)のソースを調べてみたところ、ありました。パッチデータを読み込み、検証した上で、WRMSRを使って書き込んでいます。以下に引用します。
The Linux Kernel Archives
【Linuxのカーネル(2.6.8)のソース(i386/kernel/microcode.c)からの引用】 * * Copyright (C) 2000-2004 Tigran Aivazian * * This driver allows to upgrade microcode on Intel processors * belonging to IA-32 family - PentiumPro, Pentium II, * Pentium III, Xeon, Pentium 4, etc. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. * static void do_update_one (void * unused) { unsigned long flags; unsigned int val[2]; int cpu_num = smp_processor_id(); struct ucode_cpu_info *uci = ucode_cpu_info + cpu_num; if (uci->mc == NULL) { printk(KERN_INFO "microcode: No suitable data for CPU%d\n", cpu_num); return; } /* serialize access to the physical write to MSR 0x79 */ spin_lock_irqsave(µcode_update_lock, flags); /* write microcode via MSR 0x79 */ wrmsr(MSR_IA32_UCODE_WRITE, (unsigned long) uci->mc->bits, (unsigned long) uci->mc->bits >> 16 >> 16); wrmsr(MSR_IA32_UCODE_REV, 0, 0); __asm__ __volatile__ ("cpuid" : : : "ax", "bx", "cx", "dx"); /* get the current revision from MSR 0x8B */ rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]); /* notify the caller of success on this cpu */ uci->err = MC_SUCCESS; spin_unlock_irqrestore(µcode_update_lock, flags); printk(KERN_INFO "microcode: CPU%d updated from revision " "0x%x to 0x%x, date = %08x \n", cpu_num, uci->rev, val[1], uci->mc->hdr.date); return; }
■Windowsでは?
あまり情報がありませんが、サポート情報から推測するなら、WindowsXP/Windows Server 2003以降であれば、Linux同様にマイクロコードにパッチをあてる仕組みをWindows自身が持っていると考えていいでしょう。デバイスマネージャーでプロセッサを見ると、CPU用にドライバーファイルがロードされているのがわかりますが、おそらくこのドライバー内でパッチをあてているのではと推測されます。それ以前のもの(Windows95/98/Me/NT/2000など)については、たぶん実装されていないものと思われます。
■FreeBSDでは?
FreeBSDにもLinux同様の仕組みがないかと気になり、FreeBSD4.8とFreeBSD5.3-beta5の両方のカーネルのソース(/usr/src/sys/i386)を調べてみましたが、見つけられませんでした。ないんでしょうか?FreeBSDファンなので、ちょっとがっかり。
■AMD製CPUでは?
AMDのK8(Athlon64/Opteronなど)にもマイクロコードにパッチをあてる仕組みがあるらしいです。これを使うとBIOSに内蔵してシステムの起動時にパッチをあてることも、OS上からパッチをあてることもできます。その詳細が解明されてしまっています。手順としてはMSRを使って書き込むものですが、どうもパッチデータが暗号化されていないらしいです。
(2005/10/29追記)「Revision Guide for AMD Athlon64 and AMD Opteron Processors」(Revision 3.57, August 2005)によると、マイクロコードにパッチをあてる際に使うMSRはC001_0020hのようです。ただパッチをあてる詳細手順はわかりません。(AMD64のマニュアルに記載がない。)
起草日：2004年9月18日(土)(www.marbacka.net内の別のサイトで公開)
最終更新日：2017年2月19日(日)
ソ－ス：BIOSとマイクロコード
命令アーキテクチャとマイクロアーキテクチャ
命令アーキテクチャとマイクロアーキテクチャ ……ソフトウェア的な構造とハードウェア的な構造
プロセッサがどのような命令を実行するのか，そして実行した結果がどのようになるのかなどの「プロセッサの働き」を詳細に規定したものを「命令アーキテクチャ」と呼びます。命令アーキテクチャにはプロセッサはどのような命令を実行でき，その結果どうなるのかは書かれていますが，プロセッサの中身がどのように作られているかについては規定されていません。
命令アーキテクチャに対して，「具体的な中身のハードウェア構造」を「マイクロアーキテクチャ」と呼びます。
プログラムの動作という点では，命令アーキテクチャが同じであれば同じソフトウェアを動かすことができますが，その性能はマイクロアーキテクチャで変わってくるのです。
命令アーキテクチャ発展の道
どのような命令を実行し，結果はどうなるのかという，プロセッサのそもそもの働きを規定する命令アーキテクチャも単純な計算だけでなく各種の機能が付け加えられて発展してきています。そのキーワードとしては，以下のようなものがあります。
- プログラム内蔵式コンピュータ
- 仮想記憶/仮想メモリ
- マルチプロセス
- メモリ管理機構（セグメント，ページ）
- 特権状態
- ISAの定義と互換ISA拡張
当初の電子式コンピュータは機械式の計算機を高速化したというものでしたが，計算が高速になって処理時間が短くなってくると，プログラムを入れ替える時間や，人間がキーボードの前で入力している時間は，コンピュータが遊んでしまうという無駄が目立ってきます。このため，データと同じようにプログラムをメモリに内蔵する方式の「プログラム内蔵式コンピュータ」が考案されました。
その延長として，同じプログラムを別のコンピュータでも使用できると便利ということから，実メモリ量の制約なしに大きなメモリを必要とするプログラムを動かすことができる「仮想記憶/仮想メモリ」，また，プログラムとハードウェアのインタフェースである命令アーキテクチャ「ISA」（Instruction Set Architecture）の確立や互換性を維持したISAの拡張という動きにつながっていきます。
また，キーボードの前で考えている時間は，別のユーザに使わせることでコンピュータの利用率を上げるTSS（Time Sharing System）という使い方が出てきました。そうなると，複数のプログラムがメモリ上に存在することになり，これらの管理を行う機構として「メモリ管理機構」や「特権状態」などが命令アーキテクチャに加えられて行きます。また，TSSはマルチタスクの現在のOSへと発展していきます。
仮想記憶やTSSなどはおもにOSが実現している機能ですが，メモリ管理機構や特権状態のように使用頻度が高く，ソフトウェアによる実現では性能が出ないという機能についてはハードウェアで実現するという方法が採られています。
マイクロアーキテクチャ発展の道
続いて，マイクロアーキテクチャの発展の歴史は，プログラムの実行にかかる時間を短くするという工夫の歴史です。その中で，現在のプロセッサを実現する上で主要な技術となっている以下の技術とその発展を概観しましょう。
「パイプライン処理」は流れ作業で命令を処理することにより，工場の流れ作業のように命令の処理速度を改善する技術です。そして，コンピュータは計算を行う機械なので，さまざまな演算を行うユニットを持っていますが，これらの演算を高速に実行することが重要で，とくに演算器の高速化は多くの工夫が行われきました。
x86などのCISCでは命令が複雑でパイプライン処理がやりにくかったのですが，これをパイプライン処理がやりやすい単純な命令アーキテクチャとして，小さなハードウェアで高速の実行を目指すのが「RISC」です。つまり，RISCはCISCより優れたマイクロアーキテクチャを可能とするように命令アーキテクチャを新たに作ったと考えることもできます。
パイプライン処理をさらに推し進めて流れ作業のラインを複数にして，複数の命令を並列に処理するのが「スーパースカラ実行」です。しかし，次の命令が直前の命令の計算結果を使うというようなケースは，これらの2つの命令を並列には実行できません。このため，プログラムに書いてある命令の順序を変更して，実行できる命令から先にやってしまうことで，処理速度を改善しようというのが「Out-of-Order 実行」です。また，条件分岐がある場合は，次に実行する命令がどちらになるのかわからないのですが，それを予測することによって高速化するのが「分岐予測」です。
半導体の微細化でプロセッサは高速になったのですが，DRAMメモリはメモリ容量の増大を主眼として開発が行われ，スピードの改善は比較的緩やかでした。このため，プロセッサがメモリをアクセスすると非常に長い時間がかかり，全体として性能が上がらないという問題が顕著になってきました。このメモリアクセス時間の問題をプロセッサ側に容量は小さいけれど高速のメモリを置いて解決しようというのが「キャッシュ」という技術です。
このようにして数々のプロセッサ高速化の技術が開発されてきたのですが，これらの機構の実現のために多くのトランジスタを必要とし，消費電力も大きくなって行きました。このため，個々のプロセッサにどんどんトランジスタをつぎ込んで性能を向上させるより，適当なサイズのプロセッサを複数個作るほうが消費電力あたりの性能が高いという状況になり，最近では「マルチコア」（Multi-core，複数のプロセッサコアを1つの半導体チップ上に集積する技術）が一般的になってきています。
