glibc さんの裏金疑惑！？

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
--------------------------------------------------------------------------------

TOMOYO/AKARI/CaitSith プロジェクトを SourceForge.net へ引っ越しました。

綱渡り状態が続いていた OSDN.jp ですが、全然復活の兆しが見えないので、木之本桜ちゃんの誕生日である今日、引っ越しのアナウンスをしました。

熊猫さくらは、高校１年生の時にプログラミングに出会ったので、プログラミング歴が３０年となりました。
セキュリティ分野かつうっかりミスが致命傷となるＣ言語＋カーネルという世界で過ごしてきたので、熊猫さくらは注意深いほうだと思っていたのですが、前回の投稿で「そもそも自分が担当している領域での不具合はほとんど存在しない」と言ってから１か月も経たないうちに、ファジングテストにより不具合が報告されてしまいました。はうぅ〜。

syzbot が発見した Linux カーネルの不具合の内、修正されたことが報告された件数が２／２に５０００件になりました。

今回も簡単に集計してみました。

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 で直接潰すという方法も使えそうです。

２回目の Google Open Source Peer Bonus を受賞しました。

熊猫が Linux カーネルに出会ってから２０年が経過した今春、２回目の Google Open Source Peer Bonus を受賞しました。

前回受賞時の貢献内容は紹介ページを用意できましたが、その後の４年間は Linux カーネルの不具合を地道に修正しているだけなので紹介ページはありません・・・って、これだけで終わってしまうと物足りないので、熊猫の仕事内容について紹介しようと思います。

近年の仕事内容についてですが、関係者が見落としている内容に関して、いちはやく気づいて先回りして対処することにより問題が顕在化することを予防したり、普通のサポートレベルでは解決できずに泣き寝入りしてしまうような事象に関して、報告して修正を依頼できるようになるまで切り分け調査をすることにより利用者と開発者の間を繋いだりするという仕事をしています。例えば、ウイルス対策ソフトのオンアクセススキャン処理による遅延が犯人であることを立証したり、悪意のない通信がＩＰＳ／ＷＡＦにより遮断されてしまうという問題の回避策を実装したりとかしています。
受賞対象となった Linux カーネルの不具合を修正する活動についても、 syzbot が発見した問題事象についての切り分け調査を行い、修正パッチを作成して関係者の承認を得ていくという点で、同様なのです。様々な発生パターンを見てきたことで、 syzbot が発見した問題事象だけを修正するのではなく、類似事象についても誰かが発見する前に先回りして対処できるようになってきました。知らない間に、ペンギンさんを守護する猫になりつつあるのかもしれません。

熊猫のスキルは、「どんな製品やシステムでもある程度使える」とか「特定の製品やシステムを使いこなせる」とかいうスキルではないので、検索でヒットするような名称が見当たらず、対外的な宣伝ページや社内向けスキルシートを作成する場合にどう説明したらよいのか悩んでしまいます。
情報処理安全確保支援士も LinuC 303 セキュリティも、熊猫のスキルを表現できているとは思えません。熊猫のスキルを表現することができる名称は無いものでしょうかねぇ・・・？

AKARI 1.0.48 と CaitSith 0.2-20230527 をリリースしました。

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/[e-mail]

まもなく Linux 6.0 がリリース。不具合の修正状況は・・・？

syzbot が発見した Linux カーネルの不具合の内、修正されたことが報告された件数が９／１５に４０００件になりました。

簡単な集計をしてみたところ、 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 を動作させるなど、不具合の発見と修正に関わるカーネル開発者も増えてきている感じがします。
複数の開発者が同じ不具合を修正するパッチを作成してしまうケースも見られるようになってきており、誰のパッチが採用されるかという一番乗り競争っぽくなってきました。

Tiny File Transmitter 0.11 が公開されました。

４ＧＢよりも大きなファイルを扱えるようにしてほしいという要望がありましたので、およそ１７年ぶりにＰ２Ｐ型のファイル転送ツールである Tiny File Transmitter のアップデートを行いました。

前回のリリースは TOMOYO Linux がオープンソース化されるよりも前だったので、コーディングスタイルにいろいろな癖がありましたが、今回のアップデートを行うにあたり、読みやすくするために Linux カーネルの流儀に修正しました。
また、当時はマルチスレッドの知識や経験が無かったので、安全サイドに倒すためにシングルプロセス／シングルスレッドで実装していたのですが、その代償として、長時間かかる処理をＧＵＩのイベント処理ループの中に埋め込むために「 Go To トラベル」・・・じゃなくて「 goto ラベル」の嵐になっています。ＣＵＩ環境向けのプログラミングではありえないようなスパゲッティ状態です。

結局、互換性を重視してファイルサイズを６４ビットで扱うための改修だけに留めましたが、もし最初から作り直すのであればマルチプロセスでＨＴＴＰ風のプロトコルにしていたと思います。

ＯＳＳセキュリティ技術ワークショップ２０２０で syzbot の話をしました。

今年も相変わらず Linux カーネルのバグ退治をしています。

昨年講演した The SYZBOT CTF の「その後」ですが、１年半前の記事に書いた予想が現実になりつつある気がするので、「 syzbot に追い回される開発者たち？」というタイトルで苦労話を紹介しました。

２５年前に追加されたコードに起因した不具合が発見されて、もう誰も使っていないだろうという理由で削除するとか、歴史を感じますね。

Pacemaker で softdog を利用されている方へのお知らせ

kdump の設定をしているのであれば、 softdog カーネルモジュールをロードする際のパラメータに soft_panic=1 という指定を追加していただきますようお願いします。

■お知らせの背景

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 の初期解析を行う手順をご利用ください。詳細については、（ＮＴＴ ＯＳＳセンタの契約者向けコンテンツである）「ナレッジの泉」を参照してください。