右上の隅を見ると、「城」のアイコンが追加されていました。なんだろうと思ってクリックしてみたら、ダンジョンに飛ばされました。
どうやら不具合の修正に貢献した開発者をランキング形式で表示しているページで、熊猫は２位だそうです。
でも、ダンジョンという名前が付いているからには、ゲーム画面っぽい画像の部分をクリックするとミニゲームが始まるのだろうか・・・と思ったら違いました。今後、実装されたりするのかな？（笑）
]]>
熊猫さくらはセキュリティとコンプライアンスに潰されました。
世の中の流れとして、クレームや訴訟が発生しないように振る舞うこと（契約内容に定められていることだけを実施すること）が重視されるようになり、（熊猫の得意分野である）セーフコーディングスキルや見逃されている問題点を解決するための能力（契約内容として定めることができない内容）は価値として認識されなくなったようです。
誰もが何かの専門家になることを要求され、担当外のことに対して意見を出すことが不可能になり、「取りこぼし」に起因したシステム障害や問題を解決することができなくなりました。（世の中がＡＰＩ化されてしまい、ＡＰＩで対応できないことは諦めろと言われているような感じです。）熊猫が扱うのはサポート窓口では対応してくれない（ので、問い合わせを行う側がスキルを持っていないと先へ進めない）「取りこぼし」の領域であるため、特定の製品名を使って認知してもらうこともできません。
専門性を追求しておきながら属人性の排除も追及しているようで、チームメンバーの自己紹介もありません。契約が締結されて契約期間が開始されるまで詳細な内容が共有されないため、熊猫に向いている内容かどうかも判断できません。誰がどんなスキルを持っているのかさえ知らないまま、何をしたいプロジェクトなのかを知ることもできないまま、契約でガチガチに縛られたプロジェクトが進んでいきます。当然、相手の経歴や技術レベルも知りようがないので、話が通じないことが増えました。「ガチャ」化が進んでいます。
２０年かけて、ようやく Fedora でも TOMOYO Linux が使えるようになりました。しかし、 RHEL ではまだ使えません。 RHEL で使えるようにするには、 RHEL のサブスクリプションを持っているプロジェクト側から要望を出してもらうことが必要なのですが、とあるプロジェクトに熊猫が参画してみたところ、強制アクセス制御の導入を検討するどころか、任意アクセス制御さえもまともに使えないというのが現実でした。マニュアルに沿って対応するオペレータしかおらず、内容を正確に表現するスキルがないことで、マニュアルでは対応できない想定外の事象が発生した際に、専門家による支援を有効活用できていないことが判りました。
現在でも熊猫は、ブラックボックス化した RHEL システムの解析のために TOMOYO Linux を使っていますが、熊猫が TOMOYO Linux カーネルをインストールして解析を行ったプロジェクトの関係者からは TOMOYO Linux は異物扱いされており、環境差分によるトラブル予防という理由でアンインストールされてしまう対象のままです。異物扱いされないようにするために関係者と話をする手段も存在しないため、先へ進むことができません。（ TOMOYO Linux カーネルをアンインストールせずに RHEL カーネルで運用することは、設定ファイルのバックアップを名前を変えてサーバ内に残しておくことと大差ないのですが、分業化が進んでしまってＯＳレベルの知識を共有することができなくなった現在では、それを伝えることができないのです。）
ＯＳＳ開発の世界では、誰でも意見を出すことができます。しかし、そういう経験をしたことがない人たちは、専門化／分業化が進みすぎて、数分以内の説明で理解できるような単純な内容しか扱えないようになり、落とし穴に対応することができる能力がどんどん失われているのが気がかりです。基本情報技術者やベンダ認定資格とは違う、認識する力／考える力／工夫する力の訓練をする（新入社員向けではない）研修や資格って無いものでしょうかねぇ？
]]>１００均で売っている味噌容器 (*1)と水切りネットを用意します。
まず、味噌容器の蓋を外し、底の部分を切り取ります。 (*2)
次に、蓋の代わりに水切りネットを被せます。 (*3)
完成するとこんな感じです。
虫取り網で蝶々を捕獲するのと同じ要領で、蚊を捕獲します。
捕獲したら、水切りネットの上から蚊を潰します。うまく潰せるのか疑問に思われる方もいると思いますので、実演動画１実演動画２を用意しました。 (*4)
壁などの平面に既に止まっている状態であれば成功率はほぼ１００％ですので、屋内では蚊をやっつけるという用途では殺虫剤が不要になりました。
この筒の中または水切りネットの中で潰せば、平面が汚れることもありません。プラスチックと水切りネットという組合せですので、水洗いして何度でも使えます。
*1 ２年前は四角形の味噌容器で試作した後に円形のケーキ型を選びました。 しかし、蚊の位置を確認するには透明なほうが便利だったので、透明な筒を探した結果、円形の味噌容器へと戻ってきました。（笑）
*2: 蓋も底もない土管のような形の透明な円筒を２年間探し続けたのですが、既製品としては見つかりませんでした。底の部分を切り取るのが面倒だという人は、例えば https://plasticcase.info/ で製造してもらうという方法があるようです。
*3: 味噌容器の直径が排水口の直径とほぼ一致していることが重要です。また、味噌容器の胴体が長めなので、水切りネットもできるだけ長いものが良いです。
*4: 撮影する役（知世ちゃん）と捕獲する役（桜ちゃん）を一人でこなすというのは熊猫には難しすぎるので、捕獲する部分の動画は用意していません。ご了承ください。
]]>https://forest.watch.impress.co.jp/docs/serial/yajiuma/1670651.html は見ましたが、あっという間に年度を跨いでしまったようで、既存の購読者に周知したり、メーリングリストの設定内容を引き継いだりするタイミングを逃してしまいました。（泣）
]]>https://man7.org/linux/man-pages/man3/mallopt.3.html で説明されているように、 glibc には dynamic mmap threshold という仕組みが実装されています。この仕組みが有効になっている場合、メモリの割り当て／解放を繰り返すプログラムを実行した際に、一部のメモリがＯＳに返却されなくなるという事象が発生します。これは、長期間動作を継続するプログラムにとって、無駄なメモリ消費の原因となることがあります。
物理メモリを６ＧＢ以上搭載した RHEL8 以降の環境で、以下のように約４ＧＢのメモリの割り当て／解放を繰り返すプログラムを実行した場合、ＯＳから割り当てたメモリの約８割がＯＳに返却されないまま（再割り当て要求に備えて glibc が保持したまま）の状態が発生することが観測できます。
--------------------------------------------------------------------------------
[root@localhost ~]# uname -r
4.18.0-80.el8.x86_64
[root@localhost ~]# ls -l /lib64/libc.so.6
lrwxrwxrwx 1 root root 12 May 14 2019 /lib64/libc.so.6 -> libc-2.28.so
[root@localhost ~]# gcc -Wall -O2 -x c - -o rss << EOF
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> #include <malloc.h>
>
> static void show_rss(void)
> {
> static FILE *fp = NULL;
> static char buffer[4096];
> char *cp;
> unsigned long rss;
> if (!fp) {
> fp = fopen("/proc/self/status", "r");
> if (!fp)
> return;
> }
> rewind(fp);
> buffer[fread(buffer, 1, sizeof(buffer) - 1, fp)] = 0;
> cp = strstr(buffer, "VmRSS:");
> if (cp && sscanf(cp + 6, "%lu", &rss) == 1)
> printf("\tRSS: %lu KB\n", rss);
> }
>
> int main(int argc, char *argv[])
> {
> static char *buf[256];
> int i, j, k;
> srand(0);
> for (k = 0; k < 20; k++) {
> unsigned long sum = 0;
> for (i = 0; i < 256; i++) {
> unsigned int size = (random() % 8192) * 4096;
> char *cp = malloc(size);
> if (!cp)
> return 1;
> for (j = 0; j < size; j += 4096)
> cp[j] = 1;
> sum += size;
> buf[i] = cp;
> }
> printf("%d\t+%lu KB\n", k, sum / 1024);
> show_rss();
> for (i = 0; i < 256; i++)
> free(buf[i]);
> printf("\t-%lu KB\n", sum / 1024);
> if (argc > 1)
> malloc_trim(0);
> show_rss();
> }
> return 0;
> }
> EOF
[root@localhost ~]# ./rss
0 +4122392 KB
RSS: 4123292 KB
-4122392 KB
RSS: 1380 KB
1 +4182160 KB
RSS: 4183300 KB
-4182160 KB
RSS: 1508 KB
2 +4130460 KB
RSS: 4131836 KB
-4130460 KB
RSS: 1508 KB
3 +4241984 KB
RSS: 4243208 KB
-4241984 KB
RSS: 1508 KB
4 +4198020 KB
RSS: 4199160 KB
-4198020 KB
RSS: 1508 KB
5 +4392688 KB
RSS: 4393868 KB
-4392688 KB
RSS: 1508 KB
6 +4246196 KB
RSS: 4247432 KB
-4246196 KB
RSS: 3407164 KB
7 +4039140 KB
RSS: 4040608 KB
-4039140 KB
RSS: 3407164 KB
8 +4346760 KB
RSS: 4348884 KB
-4346760 KB
RSS: 3407164 KB
9 +4369996 KB
RSS: 4371692 KB
-4369996 KB
RSS: 3407164 KB
10 +3937740 KB
RSS: 3939848 KB
-3937740 KB
RSS: 3407164 KB
11 +4044560 KB
RSS: 4046120 KB
-4044560 KB
RSS: 3407164 KB
12 +4193628 KB
RSS: 4196104 KB
-4193628 KB
RSS: 3407164 KB
13 +4061028 KB
RSS: 4062484 KB
-4061028 KB
RSS: 3407164 KB
14 +4529360 KB
RSS: 4531736 KB
-4529360 KB
RSS: 3407164 KB
15 +4101504 KB
RSS: 4102856 KB
-4101504 KB
RSS: 3407164 KB
16 +4254812 KB
RSS: 4257280 KB
-4254812 KB
RSS: 3407164 KB
17 +4335764 KB
RSS: 4339976 KB
-4335764 KB
RSS: 3407164 KB
18 +4118404 KB
RSS: 4119636 KB
-4118404 KB
RSS: 3407164 KB
19 +4049376 KB
RSS: 4050776 KB
-4049376 KB
RSS: 3407164 KB
--------------------------------------------------------------------------------
https://man7.org/linux/man-pages/man3/malloc_trim.3.html で説明されている malloc_trim() という関数を呼び出すことでＯＳに返却可能なメモリを返却することが可能になります。しかし、ソースコードに対する改修が必要となるため簡単に採用できるとは限りません。
--------------------------------------------------------------------------------
[root@localhost ~]# ./rss 1
0 +4122392 KB
RSS: 4123356 KB
-4122392 KB
RSS: 1376 KB
1 +4182160 KB
RSS: 4183280 KB
-4182160 KB
RSS: 1376 KB
2 +4130460 KB
RSS: 4131756 KB
-4130460 KB
RSS: 1376 KB
3 +4241984 KB
RSS: 4243340 KB
-4241984 KB
RSS: 1376 KB
4 +4198020 KB
RSS: 4199232 KB
-4198020 KB
RSS: 1376 KB
5 +4392688 KB
RSS: 4394072 KB
-4392688 KB
RSS: 1376 KB
6 +4246196 KB
RSS: 4247444 KB
-4246196 KB
RSS: 1380 KB
7 +4039140 KB
RSS: 4040316 KB
-4039140 KB
RSS: 1380 KB
8 +4346760 KB
RSS: 4348104 KB
-4346760 KB
RSS: 1380 KB
9 +4369996 KB
RSS: 4371196 KB
-4369996 KB
RSS: 1380 KB
10 +3937740 KB
RSS: 3939036 KB
-3937740 KB
RSS: 1380 KB
11 +4044560 KB
RSS: 4045792 KB
-4044560 KB
RSS: 1380 KB
12 +4193628 KB
RSS: 4194892 KB
-4193628 KB
RSS: 1380 KB
13 +4061028 KB
RSS: 4062356 KB
-4061028 KB
RSS: 1380 KB
14 +4529360 KB
RSS: 4530592 KB
-4529360 KB
RSS: 1380 KB
15 +4101504 KB
RSS: 4102700 KB
-4101504 KB
RSS: 1380 KB
16 +4254812 KB
RSS: 4256008 KB
-4254812 KB
RSS: 1380 KB
17 +4335764 KB
RSS: 4337904 KB
-4335764 KB
RSS: 1380 KB
18 +4118404 KB
RSS: 4119732 KB
-4118404 KB
RSS: 1380 KB
19 +4049376 KB
RSS: 4050680 KB
-4049376 KB
RSS: 1380 KB
--------------------------------------------------------------------------------
malloc_trim() を呼び出すことができない場合には、 dynamic mmap threshold を無効化するための環境変数（ MALLOC_TRIM_THRESHOLD_ MALLOC_TOP_PAD_ MALLOC_MMAP_THRESHOLD_ MALLOC_MMAP_MAX_ の内の１個以上）を設定することで緩和する（ＯＳに返却されないままとなる量を削減する）ことができます。
--------------------------------------------------------------------------------
[root@localhost ~]# MALLOC_TRIM_THRESHOLD_=131072 MALLOC_MMAP_THRESHOLD_=131072 ./rss
0 +4122392 KB
RSS: 4123480 KB
-4122392 KB
RSS: 1476 KB
1 +4182160 KB
RSS: 4183540 KB
-4182160 KB
RSS: 1476 KB
2 +4130460 KB
RSS: 4131716 KB
-4130460 KB
RSS: 1476 KB
3 +4241984 KB
RSS: 4243208 KB
-4241984 KB
RSS: 1564 KB
4 +4198020 KB
RSS: 4199580 KB
-4198020 KB
RSS: 1564 KB
5 +4392688 KB
RSS: 4394228 KB
-4392688 KB
RSS: 1564 KB
6 +4246196 KB
RSS: 4247716 KB
-4246196 KB
RSS: 1564 KB
7 +4039140 KB
RSS: 4040616 KB
-4039140 KB
RSS: 1564 KB
8 +4346760 KB
RSS: 4348128 KB
-4346760 KB
RSS: 1564 KB
9 +4369996 KB
RSS: 4371344 KB
-4369996 KB
RSS: 1564 KB
10 +3937740 KB
RSS: 3939268 KB
-3937740 KB
RSS: 1564 KB
11 +4044560 KB
RSS: 4045940 KB
-4044560 KB
RSS: 1584 KB
12 +4193628 KB
RSS: 4195188 KB
-4193628 KB
RSS: 1584 KB
13 +4061028 KB
RSS: 4062456 KB
-4061028 KB
RSS: 1584 KB
14 +4529360 KB
RSS: 4530728 KB
-4529360 KB
RSS: 1584 KB
15 +4101504 KB
RSS: 4102740 KB
-4101504 KB
RSS: 1604 KB
16 +4254812 KB
RSS: 4256256 KB
-4254812 KB
RSS: 1604 KB
17 +4335764 KB
RSS: 4337368 KB
-4335764 KB
RSS: 1604 KB
18 +4118404 KB
RSS: 4119776 KB
-4118404 KB
RSS: 1604 KB
19 +4049376 KB
RSS: 4050732 KB
-4049376 KB
RSS: 1604 KB
--------------------------------------------------------------------------------
この挙動は RHEL7 以前の環境でもある程度再現するようです。以下のように約９６ＭＢのメモリの割り当て／解放を繰り返すプログラムを実行した場合、約６３ＭＢがＯＳに返却されないままの状態が発生することが観測できます。ＧＢレベルでの差異ではないので見逃してしまうかもしれませんが、 malloc_trim() を呼び出すように修正したり環境変数を指定することにより緩和するという対処は有効なようです。
--------------------------------------------------------------------------------
[root@localhost ~]# uname -r
2.6.32-71.el6.x86_64
[root@localhost ~]# ls -l /lib64/libc.so.6
lrwxrwxrwx. 1 root root 12 Aug 18 19:13 /lib64/libc.so.6 -> libc-2.12.so
[root@localhost ~]# gcc -Wall -O2 -x c - -o rss << EOF
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> #include <malloc.h>
>
> static void show_rss(void)
> {
> static FILE *fp = NULL;
> static char buffer[4096];
> char *cp;
> unsigned long rss;
> if (!fp) {
> fp = fopen("/proc/self/status", "r");
> if (!fp)
> return;
> }
> rewind(fp);
> buffer[fread(buffer, 1, sizeof(buffer) - 1, fp)] = 0;
> cp = strstr(buffer, "VmRSS:");
> if (cp && sscanf(cp + 6, "%lu", &rss) == 1)
> printf("\tRSS: %lu KB\n", rss);
> }
>
> int main(int argc, char *argv[])
> {
> static char *buf[3];
> int i, j, k;
> srand(0);
> for (k = 28; k <= 32; k++) {
> unsigned long sum = 0;
> for (i = 0; i < 3; i++) {
> unsigned int size = (k + i) * 1048576 - (random() % 16) * 4096;
> char *cp = malloc(size);
> if (!cp)
> return 1;
> for (j = 0; j < size; j += 4096)
> cp[j] = 1;
> sum += size;
> buf[i] = cp;
> }
> printf("%d\t+%lu KB\n", k, sum / 1024);
> show_rss();
> for (i = 0; i < 3; i++)
> free(buf[i]);
> printf("\t-%lu KB\n", sum / 1024);
> if (argc > 1)
> malloc_trim(0);
> show_rss();
> }
> return 0;
> }
> EOF
[root@localhost ~]# ./rss
28 +89000 KB
RSS: 89480 KB
-89000 KB
RSS: 520 KB
29 +92084 KB
RSS: 92604 KB
-92084 KB
RSS: 30208 KB
30 +95108 KB
RSS: 95632 KB
-95108 KB
RSS: 31204 KB
31 +98168 KB
RSS: 98692 KB
-98168 KB
RSS: 64944 KB
32 +101312 KB
RSS: 133496 KB
-101312 KB
RSS: 64944 KB
[root@localhost ~]# ./rss 1
28 +89000 KB
RSS: 89476 KB
-89000 KB
RSS: 520 KB
29 +92084 KB
RSS: 92604 KB
-92084 KB
RSS: 524 KB
30 +95108 KB
RSS: 95632 KB
-95108 KB
RSS: 524 KB
31 +98168 KB
RSS: 98692 KB
-98168 KB
RSS: 524 KB
32 +101312 KB
RSS: 101836 KB
-101312 KB
RSS: 524 KB
[root@localhost ~]# MALLOC_TRIM_THRESHOLD_=131072 MALLOC_MMAP_THRESHOLD_=131072 ./rss
28 +89000 KB
RSS: 89500 KB
-89000 KB
RSS: 528 KB
29 +92084 KB
RSS: 92612 KB
-92084 KB
RSS: 528 KB
30 +95108 KB
RSS: 95636 KB
-95108 KB
RSS: 528 KB
31 +98168 KB
RSS: 98696 KB
-98168 KB
RSS: 528 KB
32 +101312 KB
RSS: 101840 KB
-101312 KB
RSS: 528 KB
--------------------------------------------------------------------------------
]]>熊猫さくらは、高校１年生の時にプログラミングに出会ったので、プログラミング歴が３０年となりました。
セキュリティ分野かつうっかりミスが致命傷となるＣ言語＋カーネルという世界で過ごしてきたので、熊猫さくらは注意深いほうだと思っていたのですが、前回の投稿で「そもそも自分が担当している領域での不具合はほとんど存在しない」と言ってから１か月も経たないうちに、ファジングテストにより不具合が報告されてしまいました。はうぅ～。
4000 件時点では 511 人の開発者により 2831 個のパッチが適用されたのに対して、 5000 件時点では 605 人の開発者により 3620 個のパッチが適用されました。
Eric Dumazet さんは 1000 件中 96 件を修正して、１位を独走中です。熊猫は 1000 件中 33 件を修正して、現在２位のようです。
$ wget -q https://I-love.SAKURA.ne.jp/syzbot-5000.html
$ awk ' { for (i = 1; i <= NF; i++) if (length($i) == 12) { print $i } }' syzbot-5000.html | awk '/[0-9a-f]{12}/{ print $0 }' | sort -u > /tmp/patches.txt
$ wc -l /tmp/patches.txt
3620 /tmp/patches.txt
$ for i in `cat /tmp/patches.txt`; do git show $i; done | grep ^Author: > /tmp/authors.txt
$ awk '{ $1 = ""; $NF=""; count[$0]=count[$0]+1 } END { for (key in count) { printf("%4d %s\n", count[key], key) } }' /tmp/authors.txt | sort -nr | wc -l
605
$ awk '{ $1 = ""; $NF=""; count[$0]=count[$0]+1 } END { for (key in count) { printf("%4d %s\n", count[key], key) } }' /tmp/authors.txt | sort -nr | head -n 22
494 Eric Dumazet
122 Tetsuo Handa
104 Cong Wang
89 Takashi Iwai
80 Eric Biggers
74 Jens Axboe
73 Pavel Skripkin
60 Florian Westphal
58 Jan Kara
54 David Howells
51 Xin Long
50 Johannes Berg
50 Alan Stern
43 Pavel Begunkov
34 Oliver Neukum
33 Paolo Abeni
33 Daniel Borkmann
31 Sean Christopherson
29 Willem de Bruijn
28 Theodore Ts'o
28 Ryusuke Konishi
28 Christoph Hellwig
ロックに起因した不具合は本当に厄介です。不完全なパッチが適用されてしまったり、メンテナがパッチを受理してくれなかったりもします。
自分がメンテナになっている領域の不具合ならば自分の判断で適用できるのですが、熊猫は自分がメンテナになっていない領域の不具合を修正している（そもそも自分が担当している領域での不具合はほとんど存在しない）ので、正しいパッチを作成するための苦労だけでなく、作成したパッチを受理してもらうための苦労もすごいです。せっかくパッチを作成しても、受理されないことで未修正のままになってしまうこともよくあります。
一例として、CVE-2023-31082があります。コンソールにログインしたユーザによる local DoS 脆弱性程度ならば、いちいち CVE 番号を申請していないのですが、誰かがこの不具合に CVE 番号を申請したようですね。この不具合は syzkaller を使っているユーザにより 2023/4/18 に報告されたようです。この脆弱性の緩和策を意図したかどうかは不明ですが、 2023/7/31 に、コンソールにログイン可能なユーザなら誰でもこの脆弱性を攻撃できるという状態から、 root ユーザだけがこの脆弱性を攻撃できるという状態にするためのパッチが提案され、採用されたようです。
しかし、同じ原因の不具合は少なくとも 2022/12/02 の時点で syzbot により報告されており、 syzbot が報告してから人間が再報告するまで４か月以上放置されていたことが判ります。
さらに遡ってみると、 2022/8/26 の時点で syzkaller を使っているユーザにより報告されていました。この時はスピンロックをミューテックスに置換するという修正が行われました。しかし、見落としがあったことが syzbot により報告され、この修正は取り消されました。
2024/1/18 に syzbot が再報告してきたのを受けて、熊猫がパッチを作成したのですが、今度はメンテナから「ファジングテストで見つかった不具合を修正する必要あるの？」と待ったをかけられてしまいました。（泣）
2022/8/26 の報告が最初かどうか判りませんが、なんだかんだで、この不具合は発見されてから少なくとも１７か月経過しても修正されていないようです。
ファジングツールである syzkaller を使って見つかった不具合は、人間が報告した場合には対処されるけれども、 syzbot が報告した場合には無視されるという感じになりつつあります。５年ほど前の記事に、「syzbotの能力が向上することで、ますますOSカーネル開発者たちがsyzbotに追い回されるようになるという説も…？」と書きましたが、その通りの状況になってしまって、逆にカーネル開発者たちが無視するようになってきたということかもしれません。
]]>作り方は超簡単で、水切りフィルター https://ec.cando-web.co.jp/item/4964549053612/ を、底板を外した筒 https://echo-k.co.jp/detail/?item_num=0736011（2023/11/16 に廃番となったので代わりの写真→） https://www.askul.co.jp/p/EA72591/ に被せるだけです。
虫取り網の網目を蚊が通過できない程度に細かくして、振り回す際には便利でも閉じ込める際には隙間の原因となってしまう棒の部分を無くして、扱いやすいようにリングの部分を筒状にした何か（名前がないのでとりあえず「蚊潰し筒」と呼んでおこう）の出来上がりです。
 |
筒を平面に対して垂直になるように押し当てることで蚊を閉じ込めます。その後、片方の手で筒を押さえたまま、他方の手でフィルターを押さえたりつまんだりすることで蚊を潰します。蚊の行動可能範囲を制限してから退治するので、閉じ込めに成功した後はゆっくりと対処できます。また、筒を押し当てることが可能な平面さえあれば、既に平面に止まっている蚊はもちろん、平面の近くを飛行中の蚊でも狙うことができます。蚊を潰す以外にも、蜘蛛のような小型の虫を捕まえて屋外へと追い払うといった使い方ができます。
この水切りフィルターは目が細かいので蚊も通過できなさそうだと思って購入し、味噌が入っていたプラスチック容器の底を切り抜いたものに被せて実験してみた結果、風が起こらないので蚊に気づかれないまま閉じ込めることができました。しかし、底を切り抜くのが面倒だと思ったのと、飛行中の蚊も狙えるように少しだけ大きなものが欲しかったので、最初から筒状のものを探した結果、このような組み合わせに至りました。
なお、既に腕などに止まっているのを発見した場合など「１秒でも早く潰してやりたいけれども、手で叩こうとすると風で吹き飛ばしてしまうので悩ましい」という場合には、底板部分が網になっている https://echo-k.co.jp/detail/?item_num=0799227 で直接潰すという方法も使えそうです。
]]>前回受賞時の貢献内容は紹介ページを用意できましたが、その後の４年間は Linux カーネルの不具合を地道に修正しているだけなので紹介ページはありません・・・って、これだけで終わってしまうと物足りないので、熊猫の仕事内容について紹介しようと思います。
近年の仕事内容についてですが、関係者が見落としている内容に関して、いちはやく気づいて先回りして対処することにより問題が顕在化することを予防したり、普通のサポートレベルでは解決できずに泣き寝入りしてしまうような事象に関して、報告して修正を依頼できるようになるまで切り分け調査をすることにより利用者と開発者の間を繋いだりするという仕事をしています。例えば、ウイルス対策ソフトのオンアクセススキャン処理による遅延が犯人であることを立証したり、悪意のない通信がＩＰＳ／ＷＡＦにより遮断されてしまうという問題の回避策を実装したりとかしています。
受賞対象となった Linux カーネルの不具合を修正する活動についても、 syzbot が発見した問題事象についての切り分け調査を行い、修正パッチを作成して関係者の承認を得ていくという点で、同様なのです。様々な発生パターンを見てきたことで、 syzbot が発見した問題事象だけを修正するのではなく、類似事象についても誰かが発見する前に先回りして対処できるようになってきました。知らない間に、ペンギンさんを守護する猫になりつつあるのかもしれません。
熊猫のスキルは、「どんな製品やシステムでもある程度使える」とか「特定の製品やシステムを使いこなせる」とかいうスキルではないので、検索でヒットするような名称が見当たらず、対外的な宣伝ページや社内向けスキルシートを作成する場合にどう説明したらよいのか悩んでしまいます。
情報処理安全確保支援士も LinuC 303 セキュリティも、熊猫のスキルを表現できているとは思えません。熊猫のスキルを表現することができる名称は無いものでしょうかねぇ・・・？
４年ほど前に、複数の LSM モジュールを同時に有効にできるようにするという LSM コミュニティの変化について紹介しました。
https://ja.osdn.net/projects/tomoyo/lists/archive/users/2019-March/001026.html
しかし、最近は LSM コミュニティが再び排他的になってきているようです。具体的には、文字列の名前で区別していた LSM モジュールを、 LSM モジュールに対応する数値のＩＤで区別するようにするという修正がまもなく採用され、このＩＤが割り当てられないと LSM モジュールを使えなくなります。
そのため、 AKARI や CaitSith のように、ローダブルカーネルモジュールとして LSM を利用している場合、他の LSM モジュールが使用するＩＤと競合することにより問題が発生するという可能性が生じます。一意に特定できないものをＩＤとして使うのは、退化です。
さらに、「メインラインに採用された LSM モジュールだけが、永続的なＩＤを獲得できる」という方針と、「レビューのための労力を確保できないことにより、新しい LSM モジュールをメインラインに追加することが年々難しくなってきている」という現実により、メインラインに採用されていない LSM モジュールは、永続的なＩＤを獲得することが困難な状況が発生することが予想されています。
つまり、「メインラインに採用されていない LSM モジュールをロックアウトする」という方向に進んでいるのです。
「ディストリビュータはサポートできないものを有効にできない」という方針と、「メインラインに採用されてもディストリビューションカーネルで有効にされないと使えない」という現実により、ローダブルカーネルモジュールとして LSM を利用するという抜け道は今後も必要になるため、熊猫は「メインラインに採用された LSM モジュールだけが、永続的なＩＤを獲得できる」という方針に猛反対しているのですが、 LSM コミュニティとしては「もう決着した話だ」という立場のようです。果たして、「 You security people are insane. I'm tired of this "only my version is correct" crap. 」の再来となるのでしょうか？
https://lkml.kernel.org/r/ff43e254-0f41-3f4f-f04d-63b76bed2ccf@I-love.SAKURA.ne.jp
簡単な集計をしてみたところ、 511 人の開発者により 2831 個のパッチが適用され、熊猫は 89 個で第３位のようです。
$ wget -q https://I-love.SAKURA.ne.jp/syzbot-4000.txt
$ awk ' { for (i = 1; i <= NF; i++) if (length($i) == 12) { print $i } }' syzbot-4000.txt | awk '/[0-9a-f]{12}/{ print $0 }' | sort -u > /tmp/patches.txt
$ wc -l /tmp/patches.txt
2831 /tmp/patches.txt
$ for i in `cat /tmp/patches.txt `; do git show $i; done | grep ^Author: > /tmp/authors.txt
$ awk '{ $1 = ""; $NF=""; count[$0]=count[$0]+1 } END { for (key in count) { printf("%4d %s\n", count[key], key) } }' /tmp/authors.txt | sort -nr | wc -l
511
$ awk '{ $1 = ""; $NF=""; count[$0]=count[$0]+1 } END { for (key in count) { printf("%4d %s\n", count[key], key) } }' /tmp/authors.txt | sort -nr | head -n 20
398 Eric Dumazet
100 Cong Wang
89 Tetsuo Handa
85 Takashi Iwai
75 Eric Biggers
71 Pavel Skripkin
64 Jens Axboe
56 Florian Westphal
47 Xin Long
41 Alan Stern
40 Johannes Berg
37 Pavel Begunkov
35 David Howells
34 Oliver Neukum
33 Jan Kara
28 Paolo Abeni
27 Daniel Borkmann
26 Willem de Bruijn
25 Sean Christopherson
25 Johan Hovold
修正件数上位１０名が作成したパッチについて統計情報を調べてみると、 Eric Dumazet さんと Cong Wang さんと Florian Westphal さんと Xin Long さんはネットワーク関連のパッチを、 Takashi Iwai さんはサウンド関連のパッチを、 Jens Axboe さんはブロック関連のパッチを、 Alan Stern さんはＵＳＢ関連のパッチを、熊猫と Eric Biggers さんと Pavel Skripkin さんは様々な分野のパッチを作成しているようです。
$ mkdir /tmp/authors/
$ for commit in `cat /tmp/patches.txt`; do git show $commit | awk ' { if (NR == 2) { $1 = ""; $NF = ""; AUTHOR = $0 } else if (NR > 3) { print $0 >> "/tmp/authors/"AUTHOR } } '; done
$ for author in /tmp/authors/*; do basename "$author"; diffstat -p1 "$author"; echo; done > /tmp/diffstat.txt
syzbot に報告されずに修正された不具合も存在しているため、誰も正確な件数は把握していないのですが、修正されたファイルの数としては、ネットワーク関連が一番多く、ドライバ関連が続くという、予想外の結果になっています。
ネットワーク関連の処理では、不具合を恐れずに適用してみて、不具合が見つかったら修正すればよいという考え方で開発が行われてきたということなのかもしれませんね。
syzbot による不具合探しが始まってから５年以上が経過し、自組織の環境で syzkaller を動作させるなど、不具合の発見と修正に関わるカーネル開発者も増えてきている感じがします。
複数の開発者が同じ不具合を修正するパッチを作成してしまうケースも見られるようになってきており、誰のパッチが採用されるかという一番乗り競争っぽくなってきました。
前回のリリースは TOMOYO Linux がオープンソース化されるよりも前だったので、コーディングスタイルにいろいろな癖がありましたが、今回のアップデートを行うにあたり、読みやすくするために Linux カーネルの流儀に修正しました。
また、当時はマルチスレッドの知識や経験が無かったので、安全サイドに倒すためにシングルプロセス／シングルスレッドで実装していたのですが、その代償として、長時間かかる処理をＧＵＩのイベント処理ループの中に埋め込むために「 Go To トラベル」・・・じゃなくて「 goto ラベル」の嵐になっています。ＣＵＩ環境向けのプログラミングではありえないようなスパゲッティ状態です。
結局、互換性を重視してファイルサイズを６４ビットで扱うための改修だけに留めましたが、もし最初から作り直すのであればマルチプロセスでＨＴＴＰ風のプロトコルにしていたと思います。
]]>昨年講演した The SYZBOT CTF の「その後」ですが、１年半前の記事に書いた予想が現実になりつつある気がするので、「 syzbot に追い回される開発者たち？」というタイトルで苦労話を紹介しました。
２５年前に追加されたコードに起因した不具合が発見されて、もう誰も使っていないだろうという理由で削除するとか、歴史を感じますね。
]]>■お知らせの背景
Pacemaker を使っているシステムが突然再起動したというお問合せは少なくありません。具体的な件数については把握していませんが、仮想化環境での発生事例が多いようです。残念なことに、ログファイルや sar を調査しても手がかりが残っておらず、原因不明のまま諦めざるを得ないという状態が何年も続いてきました。
RHEL6/CentOS6 以降の softdog カーネルモジュールには、タイムアウトの発生時に「システムを再起動させる」代わりに「カーネルパニックを発生させる」ための soft_panic というパラメータが存在しています。このパラメータを kdump の設定と組み合わせることで、タイムアウトの発生時に vmcore を取得することが可能になります。
vmcore にはタイムアウトが発生した時点の情報しか含まれないので、 vmcore を取得できればタイムアウトの原因を必ず突き止められるという訳ではありません。しかし、たくさんの事例を積み重ねることで、傾向を分析して対策を考えることはできるものと考えます。
■分析により見つかった問題点の例
Corosync main process was not scheduled for X ms (threshold is Y ms). Consider token timeout increase. というメッセージは、一般的には「カーネルが corosync プロセスにＣＰＵ時間を割り当てできなかった」という解釈／説明がされていますが、必ずしもカーネルやハードウェア側の問題を示唆している訳ではありません。１個のスレッドが様々な処理を行っているという corosync プロセスの構造上、「（カーネルは corosync プロセスにＣＰＵ時間を割り当てていたものの、 corosync プロセスが他の処理で忙しかったことにより、）このメッセージを出力するための関数を呼び出せるようになるまでに想定外の時間がかかっただけ」という可能性もあるのです。
このような問題が実際の業務負荷で発生しているのかどうかは、 vmcore を取得して確認してみないと判断できません。サポートセンタでは実際の業務負荷をかけることができないので、利用者の方々に vmcore の取得へのご協力をお願いする必要があります。
■ＮＴＴ ＯＳＳセンタを利用されている方への補足
vmcore を送付できる場合には、サイズが数十ＧＢのファイルであってもそのまま扱える「ファイルアップロード／ダウンロードシステム」をご利用ください。 vmcore を送付できない場合、あるいは、送付にかかる時間が勿体ないので自前で初期解析を行いたい場合には、 crash コマンドを用いて vmcore の初期解析を行う手順をご利用ください。詳細については、（ＮＴＴ ＯＳＳセンタの契約者向けコンテンツである）「ナレッジの泉」を参照してください。
]]>オンアクセススキャン機能を必要としている人は、業務で使っている人が多いと思うので、今すぐ RHEL 8 / CentOS 8 に乗り換えるという選択肢は難しいと思います。なので、既存環境への影響を最小限に抑えながら、 RHEL 7 / CentOS 7 環境でもオンアクセススキャン機能を使えるようにするための手順を作りました。
(1) ビルドに必要なパッケージを開発環境にインストールします。
# yum -y install gcc rpm-build yum-utils wget epel-release |
(2) curl の最新版（記事作成時点では 7.69.1 ）を開発環境でコンパイルします。
# wget https://curl.haxx.se/download/curl-7.69.1.tar.bz2 \
https://curl.haxx.se/download/curl-7.69.1.tar.bz2.asc \
https://daniel.haxx.se/mykey.asc
# gpg --import mykey.asc
# gpg curl-7.69.1.tar.bz2.asc
# tar -xf curl-7.69.1.tar.bz2
# cd curl-7.69.1
# ./configure --prefix=/usr/local/curl-7.69.1
# make
# make install
|
(3) clamav の最新版（記事作成時点では 0.102.2-4.el7 ）を開発環境でコンパイルします。
# cd
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
# yumdownloader --source clamav
# rpm --checksig clamav-0.102.2-4.el7.src.rpm
# rpm -ivh clamav-0.102.2-4.el7.src.rpm
# yum-builddep -y ~/rpmbuild/SPECS/clamav.spec
# patch -d ~/rpmbuild/SPECS/ -p0 << "EOF"
--- clamav.spec
+++ clamav.spec
@@ -4,7 +4,7 @@
## Fedora Extras specific customization below...
# EL7's curl is too old
-%if 0%{?fedora} || 0%{?rhel} >= 8
+%if 0%{?fedora} || 0%{?rhel} >= 7
%bcond_without clamonacc
%else
%bcond_with clamonacc
@@ -264,6 +264,7 @@ export have_cv_ipv6=yes
rm -rf libltdl autom4te.cache Makefile.in
autoreconf -i
%configure \
+ --with-libcurl=/usr/local/curl-7.69.1 \
--enable-milter \
--disable-clamav \
--disable-static \
EOF
# rpmbuild -bb ~/rpmbuild/SPECS/clamav.spec
|
(4) 開発環境で作成したファイルを本番環境にコピーします。なお、開発環境と本番環境が同一の場合は不要です。
# tar -cf ~/curl+clamav.tar /usr/local/curl-7.69.1/ ~/rpmbuild/RPMS/x86_64/clamd-*.rpm \
~/rpmbuild/RPMS/x86_64/clamav-*.rpm ~/rpmbuild/RPMS/noarch/clamav-*.rpm
|
# tar -xf ~/curl+clamav.tar -C / |
(5) 本番環境で clamav パッケージをインストールします。
# rpm -ivh ~/rpmbuild/RPMS/x86_64/clamd-0.102.2-4.el7.x86_64.rpm \
~/rpmbuild/RPMS/x86_64/clamav-0.102.2-4.el7.x86_64.rpm \
~/rpmbuild/RPMS/x86_64/clamav-lib-0.102.2-4.el7.x86_64.rpm \
~/rpmbuild/RPMS/noarch/clamav-data-0.102.2-4.el7.noarch.rpm \
~/rpmbuild/RPMS/noarch/clamav-filesystem-0.102.2-4.el7.noarch.rpm
|
(6) clamonacc が開発環境でコンパイルした curl ライブラリを参照する設定になっていることを確認します。
# objdump -p /usr/bin/clamonacc | grep curl NEEDED libcurl.so.4 RPATH /usr/local/curl-7.69.1/lib |
(7) 本番環境で必要な設定をしてから clamonacc を起動します。
# sed -i -e 's/^#TCP/TCP/' /etc/clamd.d/scan.conf # systemctl start clamd@scan # /usr/bin/clamonacc |