2019年08月18日

セキュリティ・キャンプ2019で使用した、熊猫のテキストを公開しました。

熊猫がプログラミングに出会ってから25年となった今年は、不具合を修正できるようにするための試行錯誤について扱いました。

不具合を踏んでクラッシュした場合、メモリダンプを取得して原因を解析することが多いかと思います。しかし、 syzbot を用いたファジングテストでは、メモリダンプを取得することが(現時点では)不可能です。また、ハングアップやストールの場合は、仮にメモリダンプを取得できたとしても、時間経過に伴う状態変化をメモリダンプから知ることはできないという限界があります。そのため、 printf() デバッグに頼らざるを得ない訳ですが、複数のスレッドが同時に printf() を呼んでしまうことで複数のメッセージが混ざってしまい、個々のメッセージを解析できなくなるという問題もあります。

そんな厳しい状況で、問題が発生した時に必要な情報をいかにして取得できるようにするかという、とても複雑で面倒な問題に熊猫は取り組んできました。講義資料は、( Linux カーネルにおける printf() に相当する)printk() を巡る試行錯誤をメインに、メモリ管理サブシステム開発者との大バトルや、ある不具合が修正されたと思ったら別の不具合が発見されたりする沼など、盛りだくさんです。とても4時間では紹介しきれません〜。(笑)

今年は、担当講義の時間以外はZトラックにお邪魔していたため、思わず突っ込む側になってしまいました。熊猫はマルウェアを解析した経験はありませんが、講義の中で strace による動的解析が紹介されていたので、ちゃっかり AKARI による追跡手法を紹介することができました。

posted by 熊猫さくら at 20:10| Comment(0) | TrackBack(0) | Linux

2019年04月27日

Google Open Source Peer Bonus を受賞しました。

サポートセンタに勤務していた時に偶然発見してしまったメモリ管理の闇が原因で、現在でも Linux カーネルのバグハンティングを続けている訳ですが、ここ1年半ほど syzbot が見つけた不具合を退治していたところ、その貢献により Google Open Source Peer Bonus を受賞してしまいました。

受賞理由の1つでもある printk() の改善が来月公開される Linux 5.1 に含まれることから、今年のセキュリティ・キャンプ全国大会では、この体験談を The SYZBOT CTFとして語ることになっています。

3年前のセキュリティ・キャンプ全国大会で語った The OOM CTF では、受講者全員の思考が停止してしまうほどの脳内 Denial of Service 攻撃になってしまいました。
現在、今年の講義で取り上げるトピックを探すためにメールのアーカイブを読み返しているところなのですが、対象範囲がメモリ管理サブシステムだけでなく Linux カーネル全体となっています。そのため、今年は3年前を超える難易度となっており、果たして受講希望者が現れてくれるのかどうか心配しています。まずはキャンプに参加してくれないことには始まりませんので、たくさんの応募をお待ちしております。

posted by 熊猫さくら at 15:57| Comment(2) | TrackBack(0) | Linux

2018年08月21日

セキュリティ・キャンプ2018で使用した、熊猫のテキストを公開しました。

直ちにアップデートを適用するなどの対処を迫られるような影響範囲の大きな脆弱性が増えてきている感触がある昨今、自分が管理している Linux システムの概要を知っておくことは、障害や脆弱性への対処を行う上で有用であると考えます。

そこで、今年のキャンプでは、サポートセンタで故障解析に携わった経験を基に、 Linux システムに関するトラブルをOS視点で調査しながら、スムーズな問題解決を行うために必要なことについて扱いました。演習で使用した仮想マシンイメージ( SHA256: f139fe85117d871ff1e87ab79b9ac891555b097f8bf6976f50a051920a687967 )も公開していますので、実際に手を動かして体験してみてください。

ちなみに、同日に開催されたセキュリティ・コアキャンプ2018の方では、一昨年度の講義で扱ったメモリ管理の闇と、その後の2年間でどこまで進んだのかについて扱いました。振り返ってみると、「しょ〜もないミス」を繰り返しているんだなぁと感じます。

posted by 熊猫さくら at 20:11| Comment(0) | TrackBack(0) | Linux

2018年01月29日

Linux 4.15 が封印解除されました。

年明け早々 Meltdown/Spectre で大騒ぎになりましたが、 Meltdown/Spectre 対応としてみんなが一斉にカーネルのアップデートを行った結果、「アップデートしたらカーネルパニックやフリーズなどが発生するようになった」という不具合報告が大量に発生して、 Bugzilla や Launchpad が大変な状況になっているようです。
メモリ管理の闇と戦っていた熊猫も、今月ばかりは、アップデートに伴う不具合報告のうち、主に Meltdown/Spectre に起因しない不具合(アップデートして発生したから Meltdown/Spectre 対策の修正が原因かと思いきや、実は全然関係ない問題だったというケース)の切り分けや修正を手伝っていました。
でも、カーネルのトラブルについて情報を取得するのに不慣れな人がほとんどで、カーネルパニック/フリーズ時のメッセージを取得できていなかったり、バージョン情報など調査に必要な情報を提示してくれなかったりと、何が起きているのか不明な不具合報告が多かったのが残念です。
まだまだ、OSレベルのトラブルに対処するノウハウは共有できていないということなんですねぇ。

先月 CELF ジャンボリーで「メモリ管理の闇」について一緒に戦ってくれる協力者を募集する発表をした際の動画が公開されています。内容は、昨年度のセキュリティ・キャンプの講義のダイジェスト+その後 Linux 4.15 までにどこまで進んだかの報告です。
どうもメモリ枯渇時の挙動を考えていないコードが多いようで、メモリ枯渇時にハングアップするバグを退治していた筈が、次第にメモリ割り当てを伴う処理全般についてバグ退治をする羽目になってきています。発表後も、(年明け早々に遭遇して 4.15-rc9 の後に修正された)メモリ圧迫時にランダムなクラッシュを引き起こすバグなど、 4.15 が封印解除されるぎりぎりまで、いろいろなバグを退治していました。

さて、封印解除といえば「カードキャプターさくら」ですね。新編が始まって「はにゃ〜ん♪」状態です。
Linux「はにゃ〜ん♪」化計画というのがあるのですが、カードを捕まえるときの掛け声が「セキュア」というのは、 TOMOYO Linux が登場する前兆だったりするのでしょうか?(笑)

posted by 熊猫さくら at 20:15| Comment(0) | TrackBack(0) | Linux

2017年11月19日

Linux カーネルのメモリ管理サブシステムの5つの特徴

  1. メモリ割り当て処理が先に進むことを保証しない
  2. 問題が発生する可能性があっても現実に起こるまでは対処しない
  3. 故意/悪意あるいはストレステストにより発生する問題には対処しない
  4. 自力で真犯人を逮捕できない一般人は相手にしない
  5. 他のカーネル開発者の関心を惹かない問題は解決されない

「え〜っ!?」って思われましたでしょうか?でも、そういう世界なんだということが解ってきました。

Linux 4.9 で追加されてしまった warn_alloc() によるハングアップを「故意/悪意あるいはストレステストでなくても現実に起こる問題」として削除するのに丸1年かかりました。いやはや、疲れます。

「 Linux システムがハングアップしたらメモリ管理を疑え!?」という諺は、まだ有効です。意図的なストレスを掛けることで発生する問題は全力で無視されてしまうため、実際のシステムで使われている負荷を掛けることで発生することが重要です。そのためには、利用者の皆様のご理解・ご協力が欠かせません。情報の取得方法を習得して、ハングアップを見つけたら、どんどん報告してくださいますよう、お願いいたします。

posted by 熊猫さくら at 17:08| Comment(0) | TrackBack(0) | Linux

2017年10月24日

Apache HTTP Server 2.4.29 で修正された Out Of Memory 自爆バグについて

仕事上、例えば vmcore のような、数ギガバイトから数十ギガバイトになる可能性のある巨大なファイルを転送する必要に迫られることがあります。しかし、セキュリティ上の理由でインターネット上のサービスを利用できないという制約があるため、いっそのこと自作してしまえと思い、大容量ファイルのアップロード/ダウンロードを行うためのプログラムを試作することにしました。その際、スクリプト言語などに依存してしまうとEOLへの対応が必要になるため、10年20年先も無改造で使い続けることができるであろうC言語で、そして、メモリリークや Web サーバ本体のバージョンアップの影響を受けないようにするため、リクエスト毎に fork()/execve() する Apache のCGIとして動作するプログラムとして開発することにしました。

しかし、たまにリクエストがエラーになったり、システムの動作が極端に遅くなったりと、どうも様子がおかしいことがありました。発生条件を切り分けていったところ、何と「スリープ処理を入れずに大量のレスポンスの送信を行うだけ」で発生していることが判明しました。親プロセスである Apache のワーカープロセスが、子プロセスであるCGIプログラムの出力を全てメモリ上に保持しようとしてしまい、 OOM killer に殺されるか、さもなくば、後続のリクエストに対する fork() ができなくなるというサービス拒否状態に陥っていたのです。

おいおい、メモリ管理で悩みたくないから子プロセスを使うという選択をしたのに、親プロセスが盛大にメモリを食い潰してどうするのよ〜?

/〜(^x^)〜/

ちなみに、RHELへのバックポートは httpd-2.4.6-76.el7 に含まれる予定になっているため、 RHEL 7.5 のリリース時に修正されるものと予想しています。

posted by 熊猫さくら at 22:31| Comment(0) | TrackBack(0) | Linux

2017年08月20日

セキュリティ・キャンプ2017で使用した、熊猫のテキストを公開しました。

昨年あたりからLSMを巡る動きが活発になってきたので、今年のセキュリティ・キャンプでは、 ウイルス対策ソフトをLSMから使うという 実習を行いました。

3年間のトラブルシューティングと、その後2年間のメモリ管理を巡る戦いにより、LSMの動向を5年間全然追いかけていなかったため、紺屋の白袴状態でした。 そのため、当初はLSMメーリングリストのアーカイブを読み直して、どのような挑戦が行われてきたのかを纏めてみるつもりでした。しかし、今年に入ってからも 「 Linux カーネルのメモリ管理機構の闇」を巡る死闘が続いており、リソースの大部分がメモリ管理機構のバグ退治に費やされてしまうという、ブラックホールから 逃げ出せない状況下での講義準備となりました。講義資料の中に OOM killer の話が何度も出てきたのは、そのせいでしょうか?(笑)

今年のキャンプでは、 DirtyCOW の件で巻き添えを喰らったり WikiPedia からブログリンク+本名暴露攻撃を喰らったりと有名ながちゃぴん先生とか、 Ryzen SEGV Battleという貴重な経験をした Sat 先生とかに会うことができて、楽しかったです。

posted by 熊猫さくら at 15:09| Comment(0) | TrackBack(0) | Linux

2016年12月31日

Linux 4.9 が封印解除されたけれども・・・

今年はずっと「 Linux カーネルのメモリ管理機構の闇」と戦い続けてきました。

Linux カーネルのメモリ管理機構は「他の誰かが自分のために進捗を出してくれているから自分は余計なことを考えなくていい」という楽観論で動いています。そして、全員が同じ考えで動いたとき、誰も進捗を出せなくなり、システムは静かにハングアップしてしまいます。なんだか、責任の所在が不明な、某市場移転問題みたいですねぇ。

Linux 4.6 で OOM reaper が導入され、 Linux 4.9 では「 OOM killer が発動できる限りは OOM livelock 状態に陥らないことを証明できる」ようになる・・・ことを目指していました。しかし、誰も進捗を出せなくなったことを知らせてくれる仕組みとして、ストールしている間は10秒毎に警告を出力するという楽観的な修正が取り込まれたことにより、 Linux 4.8 までは存在しなかった「ロックを獲得したままバッファが空になるまで永遠に待ち続けるA v.s. ロックを獲得できないことでバッファへの追加を永遠に続けるA以外の全員」という新しい OOM livelock 状態が発生してしまいました。よって、残念ながら「 OOM livelock 状態に陥らないこと」を証明できませんでした。

この問題は printk() がバッファが空になるまで永遠に待ち続けることが原因ということにされたため、バッファを空にする処理を専用のカーネルスレッドにオフロードすることで解消される見込みです。しかし、本当の原因は「ロックを獲得したままスリープしてしまうA v.s. ロックを獲得できないままビジーループをしてしまうA以外の全員」であるため、「ロックを獲得できなかった場合はスリープすることで、ロックを獲得しているAの処理を先へと進める」というのが正しい修正だと思うのですが、そのような修正を加えることにより予期せぬ副作用が発生することを恐れているため、採用される見込みはありません。問題を指摘しても、「 DoS 攻撃を受けていて手遅れだ」という返事。原因がカーネル側にあり、それを修正する方法が存在していても、想定を超える負荷が掛かったら諦めるしかないという、セキュリティとトラブルシューティングをやっている人の視点としては納得いかない世界なのです。こんな調子では、 DirtyCOW のような脆弱性が見つかるのも、当然かもなぁ。

ストールしている間は10秒毎に警告を出力するという楽観的な修正には、全員が同じ考えで動いた場合には機能しないという致命的な欠陥があり、問題が発生しているかもしれないことを知らせるという watchdog としての役割を果たせません。この処理を、専用のカーネルスレッドにオフロードすることで、全員が同じ考えで動いてしまった場合でも機能するようにするという提案を続けています。果たして、採用されるのでしょうか?

posted by 熊猫さくら at 11:34| Comment(0) | TrackBack(0) | Linux

2016年11月05日

セキュリティ・キャンプ2016で使用した、熊猫のテキストを公開しました。

RHEL 7.3 が封印解除されたので、自主規制を解除します。

今年のセキュリティ・キャンプでは、 Linux カーネルのメモリ管理機構の闇について扱いました。3年超の期間を費やし、3000通超の関連メールを送受信し、そして、今年1月からは会社の業務時間の大部分も使わせてもらいながら対応した、膨大な活動履歴の中から抽出したものです。

講義資料では、20年前から存在していたと考えられる脆弱性である CVE-2013-4312 および CVE-2016-2847 の発見から始まり、ずるずると闇に引き込まれていき、幾つかの問題について光を取り戻すまでを描いています。

CVE-2013-4312 および CVE-2016-2847 については RHEL 7.3 のカーネルで修正されていますので、信頼できないユーザがログインする可能性のあるシステムではカーネルをアップデートしてくださいね。先月、 DirtyCOW ( CVE-2016-5195 )への対処でカーネルをアップデートしたばかりだとは思いますが。

メモリ管理機構に起因したシステムのハングアップが発生しても、それを平均的なシステム管理者でも認知できる仕組みが存在しないため、どれくらいの頻度で発生しているのかについての情報はありません。サポートセンタに「今回のハングアップに関して、メモリ管理機構が原因の可能性はあるか?」と照会しても、「判断できない」としか答えられないのです。もし、「無い」とか「低い」とか回答するようなサポートセンタを見つけたら、この資料を見せてやってくださいな。(笑)

posted by 熊猫さくら at 13:30| Comment(0) | TrackBack(0) | Linux

2015年12月21日

環境変数 TZ の謎

とあるプログラムのパフォーマンス測定をしていたら、 localtime() 関数の処理で予想外に時間がかかっていることが判明しました。

そこで、 localtime() 、 localtime_r() 、 gmtime() の3つについて、どれくらいの時間がかかっているのかを簡単に計測してみました。

$ gcc -Wall -O3 -x c - << "EOF"
#include <stdio.h>
#include <time.h>

int main(int argc, char *argv[])
{
        int i;
        time_t now = time(NULL);
        struct tm tm0 = { };
        struct tm *tm;
        if (argc == 3)
                for (i = 0; i < 100000000; i++)
                        tm = gmtime(&now);
        else if (argc == 2)
                for (i = 0; i < 100000000; i++)
                        tm = localtime_r(&now, &tm0);
        else
                for (i = 0; i < 100000000; i++)
                        tm = localtime(&now);
        printf("%04u/%02u/%02u %02u:%02u:%02u\n",
               tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday, tm->tm_hour,
               tm->tm_min, tm->tm_sec);
        return 0;
}
EOF

localtime()localtime_r()gmtime()
$ time ./a.out$ time ./a.out 1$ time ./a.out 1 2

仮想化環境での簡単な計測なのであまり正確ではありませんが、確実に localtime() 関数は gmtime() 関数と比べて遅いようです。

localtime()localtime_r()gmtime()
real 2m6.615s
user 0m51.170s
sys 1m15.550s
real 0m38.278s
user 0m38.309s
sys 0m0.000s
real 0m3.995s
user 0m3.994s
sys 0m0.002s

この原因は、 localtime() 関数は呼び出しの度に、 /etc/localtime の内容が変化していないかどうかを確認するために stat() システムコールを発行しているためです。

CentOS 7 では /etc/localtime が ../usr/share/zoneinfo/Asia/Tokyo へのシンボリックリンクとなっているため、 stat() システムコールでの無駄を減らすために、 /etc/localtime を /usr/share/zoneinfo/Asia/Tokyo のコピーに置き換えて実験してみました。シンボリックリンクを辿らないで済む効果はあるようです。

localtime()localtime_r()gmtime()
real 1m22.785s
user 0m52.446s
sys 0m30.407s
real 0m37.940s
user 0m37.970s
sys 0m0.000s
real 0m3.951s
user 0m3.954s
sys 0m0.000s

次に、環境変数 TZ で zoneinfo ファイルの場所を指定( export TZ=:Asia/Tokyo )して実験してみました。すると、 stat() システムコールが発行されなくなくなった分、 localtime() 関数が速くなりました。

localtime()localtime_r()gmtime()
real 0m39.887s
user 0m39.919s
sys 0m0.002s
real 0m37.597s
user 0m37.629s
sys 0m0.000s
real 0m3.970s
user 0m3.971s
sys 0m0.002s

次に、環境変数 TZ でタイムゾーン情報を指定( export TZ=JST-9 )して実験してみました。すると、 localtime_r() 関数が gmtime() 関数と同じレベルまで速くなりました。

localtime()localtime_r()gmtime()
real 0m8.735s
user 0m8.740s
sys 0m0.003s
real 0m6.733s
user 0m6.738s
sys 0m0.000s
real 0m6.647s
user 0m6.651s
sys 0m0.001s

でも、ちょっと不思議なことが起きてますよね?何故か、 gmtime() 関数は環境変数 TZ にタイムゾーン情報が指定されていると遅くなってしまうようです。

posted by 熊猫さくら at 19:59| Comment(0) | TrackBack(0) | Linux

2015年08月18日

セキュリティ・キャンプ2015で使用した、熊猫のテキストを公開しました。

去年から今年にかけて、例えば Shell Shock 脆弱性のような、OSレイヤーでの重大な脆弱性が見つかり、セキュリティ意識の高い人たちの間では「 SELinux を使おうよ」という機運が高まっているのかもしれません。しかし、サポートセンターでの経験より、「 SELinux を使ってトラブルが起きても対処できない」という人たちも大勢いることが判りました。そこで、改めて「OSの挙動を知って、OSレイヤーのセキュリティについて考えてみよう」と思い、今年度は「 TOMOYO / AKARI / CaitSith ハンズオン」というテーマにしました。

読むためのPDF版コピペするためのテキスト版

今回のテキストは、事前学習資料部分と当日学習資料部分の2部構成になっています。

事前学習資料部分では、「講義で使う環境に慣れてもらう」ことを意図して、「 PXE ブートして sl コマンドが走る Linux 環境を作る」ことに挑戦していただきました。 Scientific Linux ならぬ、 SL Linux です。(これは、昨年度のキャンプの企業見学からの帰りのバスの中での雑談から思いついたネタです。)

当日学習資料部分では、 TOMOYO をメインライン化するまでのドタバタ劇とか、3年間 RHEL システムのトラブルシューティング業務に従事して痛感した組織の問題点とかのような、技術的に Linux システムに詳しくない人にも何かの役に立つ話を交えたいと思いました。また、緊急コラム「 bash 脆弱性( CVE-2014-6271 )の影響範囲の調査方法について」が掲載されました。で「あまりに dis りすぎたため、公開したら怒られそうな内容になってしまいました」と書いたように、一昨年/昨年のテキストについては公開することを躊躇っていましたが、責任をとらないお偉いさんたちが蔓延していく現在の日本の危機的状況を見て、「来年では間に合わない」と判断し、過去テキストも含めて全テキストへのリンクを含めることにしました。

当日学習で使用した VirtualBox 向けのVMイメージは、 http://jaist.dl.sourceforge.jp/caitsith/63583/ からダウンロードできます。(ただし、サイズが大きいので、1か月後くらいに削除するつもりです。テキストでは CentOS 6 / CentOS 7 / Ubuntu 14.04 の3つしか言及していませんが、受講者の中に Arch Linux ユーザが居ましたので、 Arch Linux 用のVMイメージも用意しました。)

キャンプの様子は http://togetter.com/li/859151 から察していただければと思います。他の講師の方々が公開された資料や、参加者の反応なども見つけることができます。

posted by 熊猫さくら at 01:41| Comment(0) | TrackBack(0) | Linux

2015年04月03日

makedumpfile コマンドの罠

Red Hat 社のナレッジ の中に、 vmcore ファイルのファイルサイズを削減するには makedumpfile -d 31 を使ってフィルタリングするようにという記述があります。しかし、 RHEL 6 および RHEL 7.0 に含まれている makedumpfile コマンドには、本来はフィルタリングされるべき Transparent Huge Pages の内容がフィルタリングされないという不具合があります。その結果、 vmcore ファイルのファイルサイズが必要以上に大きくなったり、 vmcore ファイル内に機密情報が残存しやすくなったりします。この不具合は RHEL 7.1 に含まれている kexec-tools パッケージで修正され、 RHEL 6 系についても RHEL 6.7 で修正予定とのことです。

RHEL 6.7 がリリースされるまでの暫定対処としては、サポート対象外の方法ではありますが、 RHEL 7.1 用の kexec-tools パッケージを RHEL 6 環境にインストールして使うことができます。 CentOS 6 環境に CentOS 7.1 用の kexec-tools パッケージをインストールする例を以下に示します。既存の環境を壊さないように、 rpm コマンドの実行時に --root オプションを指定しています。

# source=http://ftp.jaist.ac.jp/pub/Linux/CentOS/7.1.1503/os/x86_64/
# dest=~/kexec-tools/
# rpm --root $dest/ --import $source/RPM-GPG-KEY-CentOS-7
# rpm --root $dest/ --nodeps --noscripts -ivh $source/Packages/kexec-tools-2.0.7-19.el7.x86_64.rpm $source/Packages/snappy-1.1.0-3.el7.x86_64.rpm $source/Packages/lzo-2.06-6.el7_0.2.x86_64.rpm $source/Packages/elfutils-libs-0.160-1.el7.x86_64.rpm $source/Packages/xz-libs-5.1.2-9alpha.el7.x86_64.rpm $source/Packages/glibc-2.17-78.el7.x86_64.rpm

取得済みの vmcore ファイルを再度フィルタリングする際の例を以下に示します。 CentOS 6 用ではなく CentOS 7.1 用のライブラリが参照されるようにするために、 LD_LIBRARY_PATH= オプションの指定と /lib64/ld-2.17.so 経由での起動をしています。

# dest=~/kexec-tools/
# LD_LIBRARY_PATH=$dest/lib64/:$dest/usr/lib64/ $dest/lib64/ld-2.17.so $dest/sbin/makedumpfile -l -d 31 フィルタ前のvmcoreファイル フィルタ後のvmcoreファイル

kexec-tools-2.0.0-280.el6.x86_64 がインストールされている CentOS 6.6 環境に、上記の手順で CentOS 7.1 の kexec-tools-2.0.7-19.el7.x86_64 をインストールし、 メモリ 2048MB 中の 1536MB を特定のパターンで埋め尽くした状態で取得した vmcore ファイルを、上記の手順で再度フィルタリングした場合のサイズの変化例を以下に示します。

使用する
パターン
フィルタオプションvmcore ファイルの
サイズの変化
0-d 31100,739,352

91,312,408
-l -d 3129,346,091

20,415,428
1-d 311,706,537,640

91,736,744
-l -d 3140,430,575

20,533,033
rand() 関数の
戻り値
-d 311,705,867,632

91,050,376
-l -d 311,634,827,177

20,510,161

上記は意図的に特定のパターンで埋め尽くした場合に生じる極端な結果ですが、現実のメモリ使用状況でもある程度の効果を期待できる筈です。

posted by 熊猫さくら at 21:11| Comment(0) | TrackBack(0) | Linux

2015年03月31日

最終回「防災訓練ノススメ」が掲載されました。

今回はトラブルに遭遇する前に何ができるかという話です。

OSSセンタで3年間、問合せ対応を行ってきましたが、「発生したトラブルについての原因と対策を教えてほしい」という問合せはあっても、「トラブルが発生した場合の対処手順を教えてほしい」という問合せはありませんでした。それだけ、「どのようなトラブル発生事例があるのか」や「どのようなトラブルが発生しうるのか」についての共有ができていないということなのだと思います。

でも、「どのようなトラブル発生事例があるのか」や「どのようなトラブルが発生しうるのか」を知っているOSSセンタ側も、「トラブルが発生した場合の対処手順」を用意できているとは言い難い状況でした。熊猫はカーネルの開発経験があるため、カーネルクラッシュダンプの取得に関する問合せや解析依頼に対応しながら、取得手順や初期解析の手順を作成してきました。その第一歩が、今回の話に登場した「ナレッジの泉」に反映されています。もちろん、システムに固有の部分については対応できませんが、共通する部分については「トラブルが発生した場合の対処手順」を考えておくべき時期が来たのではないかと思います。

posted by 熊猫さくら at 22:33| Comment(0) | TrackBack(0) | Linux

2015年03月17日

第17回「プログラミング体験ノススメ」が掲載されました。

今回はプログラムを自作してみようという話です。

「たまゆら」を観ていると「 ARIA 」の世界を思い出してしまうのですが、自分の手でやっている感触というんでしょうかね。熊猫は、そういう癒し系アニメに出会うと好きになってしまいます。提供されたAPIを呼び出して結果を待つだけではなく、「ああでもない、こうでもない」と考えて行動した人だけが辿り着ける「(細かな問題点にも気付く)気配り/思いやりスキル」が存在するのだと思います。

世の中がそういうスキルを持つ人たちで満たされていれば対処する必要のない脆弱性に関して重箱の隅をつつき続けた結果、当初は議論に値しないと乗り気でなかったため「30分で終わる」と思っていたらしい Linux Storage filesystem and MM summit での議論が、2時間くらい続く大炎上となった模様です。熊猫は留守番でしたので内容は知りませんが、 LWN.net の記事によると、 3.19-rc6 後に紛れ込んだ予期せぬ挙動の変化を容認する(ファイルシステムエラーなどが起こらないように呼び出し側を修正していく)方向になったようで、そのためのパッチが LKML に投稿されています。ディストリビューションカーネルのデフォルトの挙動にして、エンドユーザにメモリ枯渇時のカーネルの不具合を見つけてもらうことを期待しているようですが、それは無理すぎる気が・・・。

posted by 熊猫さくら at 21:47| Comment(0) | TrackBack(0) | Linux

2015年03月03日

第16回「 kernel-debug ノススメ」が掲載されました。

今回は デバッグ用カーネルの紹介です。でも、デバッグ用カーネルの紹介だけで1話持たせるのは無理があるので、過負荷試験の話も入れました。

今までは「システムがダウンするくらいにまでメモリ負荷を掛けたら、いつ回復するか予測できないストール状態に陥るのは当然だ。そのような負荷を掛けたユーザのほうが悪い」と相手にされなかったのですが、実は「無限ループに陥るトドメの一撃」を喰らわせていたのはユーザ側ではなくメモリ管理機構側だったようです。
前回紹介したメモリ枯渇時の挙動についての議論が、 3.19-rc6 後に紛れ込んだ予期せぬ挙動の変化をきっかけに、一気に動き出しました。
ext4 でファイルシステムエラーが頻発したり、 xfs でページフォールトするだけで OOM killer が発生したりと、全く使い物にならなくなってしまうことが確認されたため、とりあえずは元の挙動に戻されました
そして、 mm のメンテナと ext4 のメンテナと xfs のメンテナとの間で将来に向けてどう修正していくのかの議論の最中なのですが、熊猫が欲している「既存のカーネルにバックポート可能な修正方法」についての話が完全に置いてけぼり状態になっています。
メモリ割り当て要求が原因のシステムフリーズとさよならできるようになる日が来るのはまだ遠いのかなぁ。
来週、ボストンで Linux Storage filesystem and MM summit という 会議があるので、そこで何らかの進展があることを期待しています。

posted by 熊猫さくら at 20:56| Comment(0) | TrackBack(0) | Linux

2015年02月17日

第15回「フォールトインジェクションノススメ」が掲載されました。

今回は SystemTap を使ってエラーを発生させるというちょっと怖いお話です。でも、ここでは目を離した隙にカーネルの挙動が変化しているという別の方向で怖い話をしたいと思います。

使い方1で紹介した不具合は RHEL 6/7 カーネルにバックポートされましたが、修正されたことを知るのは面倒です。というのも、エラータのページにはセキュリティ上の不具合の修正内容についてしか言及されておらず、「その他の修正内容についてはテクニカルノートを見てね」と書かれているのに従ってテクニカルノートのページをチェックしても、今回の不具合に該当しそうな内容が見当たりません。実は、 rpm パッケージの変更履歴の説明文をチェックするかソースコードの差分をチェックして初めて、「あ、修正されたんだな」と判るようになっていたのです。テクニカルノートには全修正内容が網羅されていると思っていると、落し穴にはまるかもしれないということですね。

使い方2で紹介した挙動は、 3.19-rc6 がリリース(1/25)されてから 3.19 がリリース(2/8)されるまでの僅かな間に、 __GFP_FS が含まれていない場合にはメモリ枯渇時に OOM Killer を発動させずに諦めるという変更が適用されてしまいました。 linux-next.git でテストを行って問題が無いことを確認してから linux.git の -rc1 がリリースされるまでにマージするというのが本来の手順なのですが、その手順をすっとばされた訳です。ファイルシステムより低いレイヤーでのメモリ割り当てがメモリ枯渇時に失敗してしまうようだと、ファイルシステムエラーが多発してしまうので困ると思うのですが。そういう変更を適用するのなら、 __GFP_NOFAIL が必要な個所を全て洗い出して修正してからにしてほしかったんだけどなぁ。

posted by 熊猫さくら at 22:56| Comment(0) | TrackBack(0) | Linux

2015年02月03日

緊急コラム「 glibc 脆弱性( CVE-2015-0235 )の影響範囲の調査方法について」が掲載されました。

ルイージ@お化け屋敷のような、次から次へと襲い掛かってくる問合せの嵐に困っています。

glibc の不具合や脆弱性が見つかる度に、影響を受けるプログラムの調査方法を説明するというのも馬鹿げた話ですので、今回の glibc 脆弱性を機に、緊急コラムとして調査方法を説明することにしました。
一昨日考えた内容を急いでダンプしたものなので、全てを網羅できている訳ではありません。でも、影響範囲を調査することの難しさに気付いて素直にアップデートをしていただけるのなら、この記事を作成した意味はあると考えています。

今回の脆弱性については幽霊に振り回されすぎている感がありますが、システムの動作を再確認してみるチャンスかもしれません。任意のホスト名を渡すことができるかどうかをソースコードレベルで網羅的に調査してみたら、OSコマンドインジェクションのような、今まで見落としていた脆弱性が見つかってもおかしくないと思っています。

posted by 熊猫さくら at 21:15| Comment(0) | TrackBack(0) | Linux

2015年02月02日

第14回「 SystemTap ノススメ」が掲載されました。

今回は SystemTap を使って挙動を追跡するというお話です。

とあるシステムで、 Pacemaker を起動してから約70秒後にシステムが予期せぬ再起動をしてしまうというトラブルが発生していました。再起動する直前だけディスクI/Oが多いという傾向が見られたため、何らかのディスクI/Oに関するトラブルに巻き込まれた結果、 /dev/watchdog への書き込みが遅延して watchdog タイムアウトによるリセットが発生しているのではないかと疑ったのですが、原因を掴めませんでした。

そこで、再起動要求が発生した時点の kdump を取得することにより、誰が再起動要求を発生させているのか/どうして再起動要求を発生させることになったのかを調査するために、今回紹介した SystemTap スクリプトを仕掛けて事象を再現してもらいました。すると、何と sfex_daemon という監視プログラムが /proc/sysrq-trigger に b を書き込んだことによるリセットが発生していたことが判明したのです。これをきっかけに、設定の誤りが予期せぬ再起動の原因であったことが判明し、トラブルを解決することができました。

sfex_daemon のソースコードによると、普段はスリープしながら、定期的に update_lock() を呼び出してロックの状態を確認し、異常を検知した場合には failure_todo() を呼び出しているようです。 failure_todo() は cl_log() という関数の中から syslog() 関数を呼び出すことで syslog デーモンにログメッセージを送信後、 /proc/sysrq-trigger に b を書き込んでいるようです。では、何故 syslog() 関数を介して送信した筈のログメッセージが、 syslog ファイルに残っていなかったのでしょうか?実は、 syslog() 関数を介して syslog デーモンにログメッセージを出力する方法には、2つの落し穴があったのです。

1つ目の落し穴は、 rsyslog の version 3 からは、デフォルトで非同期書き込みを行うようになっている点です。そのため、非同期書き込み後すぐに再起動要求が発生してしまっては、ログに残すことができません。2つ目の落し穴は、 syslog() 関数を介して syslog デーモンにログメッセージを出力する方法では、 syslog デーモンがログメッセージを出力するよりも前に syslog() 関数が復帰してしまうため、たとえ同期書き込みを行うようになっていたとしても、同期書き込みの完了を待たずに再起動要求が発生してしまい、ログに残すことができません。

RHEL 7 の登場により、3つ目の落し穴も発見されました。 RHEL 7 の場合はデフォルトのファイルシステムが ext4 から xfs に変更されたため、 ext 系ファイルシステムで行われていた5秒毎の writeback も行われなくなっています。そのため、 RHEL 7 においては、明示的に sync() 関数などを呼ばないと、問題事象発生直前のログが残っていないという可能性が一層高くなっています。

再起動直前のログを確実に残したい場合、 syslog デーモンに頼っていては駄目なのかもしれません。今後 RHEL 7 のシステムが増えてくるに従い、問題事象発生時のログを如何に残すかという課題が出てきそうです。カーネルメッセージであればシリアルコンソールや netconsole 経由で取得するという方法が使えます。アプリケーションのメッセージについても自力でローカルとリモートの両方にログを出力するとかしたほうが良いのかなぁ?

明日は節分ですって? 幽霊は〜外〜。アップデートは〜内〜。(謎)

posted by 熊猫さくら at 22:00| Comment(0) | TrackBack(0) | Linux

2015年01月20日

第13回「 TaskTracker ノススメ」が掲載されました。

今回は Hadoop のお話・・・ではなくて、緊急コラム「 bash 脆弱性( CVE-2014-6271 )の影響範囲の調査方法について」の中で紹介していた System Call Auditing のログの中に TOMOYO Linux 風のプロセス実行履歴を埋め込むというお話です。
メインラインカーネルへのマージを目指してMLに提案中ですので、コードの内容が若干変化しています。興味のある方は、MLでの議論に参加してコメントを頂けると嬉しいです。

posted by 熊猫さくら at 22:42| Comment(0) | TrackBack(0) | Linux

2015年01月06日

第12回「 System Call Auditing ノススメ」が掲載されました。

今回は犯人探しのお話です。セキュリティ目的で使う場合には SELinux などと併用して監査ログの改ざんなどをされないようにする必要がありますが、デバッグ目的で使う場合には Red Hat 社のサポートが受けられる標準機能なので気軽に試せるかと思います。

熊猫はコーヒーブレークの内容にはノータッチなのですが、今回のコーヒーブレークの内容には突っ込みを入れておこうと思います。
問題を解決するのに必要な情報が提供されない理由のひとつに、「サポート技術者が何をもとに調査や解析を行うかがあまり知られていない」ことにあるという点は同意します。しかし、問題が起きたときに、「どんな問題が起きているのか判らない」「どこに必要な情報が保存されているのか判らない」「どうすれば必要な情報を取得できるのか判らない」「トラブルの発生後に情報取得のツールやコマンドを提示されても、すぐに使いこなせるとは限らない」など、「製品別に調査に必要な情報の一覧を作っておくだけでは対処できない」部分も多いと思うのです。
OSSであってもシステムの安定稼働とセキュリティが年々重要視されてきている中で、お客様がトラブルに遭遇したときに自力で情報収集や一次切り分けができるスキルをどうやって共有/継承していくのかという「教育」の問題でもあり、問題解決のお手伝いをする組織としてどう対処していくのかを考え続けなければいけない課題でもあると思うのです。熊猫が安心して年次有給休暇を取得できるようになるためにも、ね。

posted by 熊猫さくら at 22:02| Comment(0) | TrackBack(0) | Linux