| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 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 | 27 | 28 | 29 | 30 |
Linux カーネル 7.0 が 2026/4/13 にリリースされ、 syzbot が報告した不具合の修正件数も７０００件を超えました。
５０００件が７０００件になるまでに約２年、新しく混入した不具合が早期に修正されるようになってきたものの、古くから存在している不具合はなかなか修正されずに残っているようです。
右上の隅を見ると、「城」のアイコンが追加されていました。なんだろうと思ってクリックしてみたら、ダンジョンに飛ばされました。
どうやら不具合の修正に貢献した開発者をランキング形式で表示しているページで、熊猫は２位だそうです。
でも、ダンジョンという名前が付いているからには、ゲーム画面っぽい画像の部分をクリックするとミニゲームが始まるのだろうか・・・と思ったら違いました。今後、実装されたりするのかな？（笑）
熊猫さくらはセキュリティとコンプライアンスに潰されました。
世の中の流れとして、クレームや訴訟が発生しないように振る舞うこと（契約内容に定められていることだけを実施すること）が重視されるようになり、（熊猫の得意分野である）セーフコーディングスキルや見逃されている問題点を解決するための能力（契約内容として定めることができない内容）は価値として認識されなくなったようです。
誰もが何かの専門家になることを要求され、担当外のことに対して意見を出すことが不可能になり、「取りこぼし」に起因したシステム障害や問題を解決することができなくなりました。（世の中がＡＰＩ化されてしまい、ＡＰＩで対応できないことは諦めろと言われているような感じです。）熊猫が扱うのはサポート窓口では対応してくれない（ので、問い合わせを行う側がスキルを持っていないと先へ進めない）「取りこぼし」の領域であるため、特定の製品名を使って認知してもらうこともできません。
専門性を追求しておきながら属人性の排除も追及しているようで、チームメンバーの自己紹介もありません。契約が締結されて契約期間が開始されるまで詳細な内容が共有されないため、熊猫に向いている内容かどうかも判断できません。誰がどんなスキルを持っているのかさえ知らないまま、何をしたいプロジェクトなのかを知ることもできないまま、契約でガチガチに縛られたプロジェクトが進んでいきます。当然、相手の経歴や技術レベルも知りようがないので、話が通じないことが増えました。「ガチャ」化が進んでいます。
２０年かけて、ようやく 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://sourceforge.net/projects/tomoyo/lists/tomoyo-users_ja から再登録をお願いします。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1670651.html は見ましたが、あっという間に年度を跨いでしまったようで、既存の購読者に周知したり、メーリングリストの設定内容を引き継いだりするタイミングを逃してしまいました。（泣）
OOM Killer 対策として消費メモリを削減する方法を探していたら、驚きの情報を見つけましたので、Ｃ言語で検証してみました。
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 カーネルに出会ってから２０年が経過した今春、２回目の Google Open Source Peer Bonus を受賞しました。
前回受賞時の貢献内容は紹介ページを用意できましたが、その後の４年間は Linux カーネルの不具合を地道に修正しているだけなので紹介ページはありません・・・って、これだけで終わってしまうと物足りないので、熊猫の仕事内容について紹介しようと思います。
近年の仕事内容についてですが、関係者が見落としている内容に関して、いちはやく気づいて先回りして対処することにより問題が顕在化することを予防したり、普通のサポートレベルでは解決できずに泣き寝入りしてしまうような事象に関して、報告して修正を依頼できるようになるまで切り分け調査をすることにより利用者と開発者の間を繋いだりするという仕事をしています。例えば、ウイルス対策ソフトのオンアクセススキャン処理による遅延が犯人であることを立証したり、悪意のない通信がＩＰＳ／ＷＡＦにより遮断されてしまうという問題の回避策を実装したりとかしています。
受賞対象となった Linux カーネルの不具合を修正する活動についても、 syzbot が発見した問題事象についての切り分け調査を行い、修正パッチを作成して関係者の承認を得ていくという点で、同様なのです。様々な発生パターンを見てきたことで、 syzbot が発見した問題事象だけを修正するのではなく、類似事象についても誰かが発見する前に先回りして対処できるようになってきました。知らない間に、ペンギンさんを守護する猫になりつつあるのかもしれません。
熊猫のスキルは、「どんな製品やシステムでもある程度使える」とか「特定の製品やシステムを使いこなせる」とかいうスキルではないので、検索でヒットするような名称が見当たらず、対外的な宣伝ページや社内向けスキルシートを作成する場合にどう説明したらよいのか悩んでしまいます。
情報処理安全確保支援士も LinuC 303 セキュリティも、熊猫のスキルを表現できているとは思えません。熊猫のスキルを表現することができる名称は無いものでしょうかねぇ・・・？
AKARI と LKM-based LSM 版の CaitSith に関して、プログラム実行要求時の権限チェックを回避できてしまう不具合を修正しています。
https://ja.osdn.net/projects/tomoyo/lists/archive/users/2023-May/001029.html
４年ほど前に、複数の 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