以降の記述はバグの再現をとったり、パッケージの差分をメモした内容です。詳細に興味がなければスキップしてください
続きを読むこれの続きを調べていた
SPRM からソースを展開して、問題のあるカーネルとそうでないカーネルとの diff を見ながら、関係がありそうな変更を削ったり/足したりしながら手元でビルドして試したころ、下記の変更によって起きる問題だと絞り込めた
diff -ru /home/vagrant/rpmbuild/BUILD/kernel-3.10.0-862.el7/linux-3.10.0-862.el7.centos.x86_64/arch/x86/kernel/entry_64.S /home/vagrant/rpmbuild/BUILD/kernel-3.10.0-862.2.3.el7/linux-3.10.0-862.2.3.el7.x8 6_64/arch/x86/kernel/entry_64.S --- /home/vagrant/rpmbuild/BUILD/kernel-3.10.0-862.el7/linux-3.10.0-862.el7.centos.x86_64/arch/x86/kernel/entry_64.S 2018-03-21 21:40:12.000000000 +0000 +++ /home/vagrant/rpmbuild/BUILD/kernel-3.10.0-862.2.3.el7/linux-3.10.0-862.2.3.el7.x86_64/arch/x86/kernel/entry_64.S 2018-04-30 14:05:40.000000000 +0000 @@ -1400,7 +1400,7 @@ .pushsection .kprobes.text, "ax" paranoidzeroentry_ist debug do_debug DEBUG_STACK -paranoidzeroentry_ist int3 do_int3 DEBUG_STACK +zeroentry int3 do_int3 errorentry stack_segment do_stack_segment #ifdef CONFIG_XEN zeroentry xen_debug do_debug
上記の変更を取り除くと、SIGSEGV は治まった.
https://git.centos.org/summary/rpms!kernel.git を git clone して imports/c7/kernel-3.10.0-862.2.3.el ブランチの SPECS/kernel.spec を見て見るに下記の変更っぽい
%changelog
* Mon Apr 30 2018 Rado Vrbovsky <rvrbovsk@redhat.com> [3.10.0-862.2.3.el7]
- [x86] kvm: fix icebp instruction handling (Paolo Bonzini) [1566849 1566845] {CVE-2018-1087}
- [x86] entry/64: Don't use IST entry for #BP stack (Paolo Bonzini) [1567084 1567083] {CVE-2018-8897} 👈
(CentOS で spec ファイルの %changelog と diff を付き合わせるよい方法がわからない)
もともと upstrem には下記のコミットでマージされたようだ.
自分が見ていたコードとはだいぶ違う. バックポートの際に変更が加わっているのだろう
CVE-2018-8897 の fix である
コードを追って見たものの、どうやって不具合に至るのかという詳細まではよく分からない 🙃
/sys/kernel/debug/tracing がぶっこわれているということで、 似たような問題が下記で議論されたり パッチが revert されていた
bugs.centos.org にどうやってレポートするといいか考えている
6/24(日) 前日から天気が崩れていたが、午後にかけて晴れ始めたタイミングで出走。が、湿気と日差しと強烈でバテたので、すぐ帰った
90km 走って終わり. 夏場は涼しい時間に山に入って、暑さを避けないと距離を稼げないなぁ
雨上がりで澄んだ空気
途中、所沢のあたりで蝉の鳴き声を聞いた気がする.
日高市の巾着田のあたりから奥武蔵グリーンラインに入ろうとしたのだけど、なんと通行止め
ここで完全に気力がはてた. 帰って風呂に入る決意を固める
帰路で川越を通過。喜多院で小休憩.
観光客も少なくてのんびりしてた
これの続き.
分かっている事をまとめて 0014961: perf probe / perf record cause segmentation fault - CentOS Bug Tracker にバグレポートをだして Confirm してもらえました.
上記のエントリを書いたのだが、VM を作り直したところ再現がとれなくなったので改めて検証しなおした.
(別のバグを調査した VM を使いまわしたのだが、パッケージインストール後にカーネルパニックを起こした影響かでパッケージ/ファイルの一部が欠損しまったらしい)
[vagrant@localhost ~]$ uname -a Linux localhost.localdomain 3.10.0-862.3.3.el7.x86_64 #1 SMP Fri Jun 15 04:15:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [vagrant@localhost ~]$ rpm -q perf perf-3.10.0-862.3.3.el7.x86_64 [vagrant@localhost ~]$ rpm -q glibc glibc-2.17-222.el7.x86_64
perf probe で malloc を追加する
[root@localhost ~]# perf probe -x /usr/lib64/libc.so.6 malloc Added new event: probe_libc:malloc (on malloc in /usr/lib64/libc-2.17.so) You can now use it in all perf tools, such as: perf record -e probe_libc:malloc -aR sleep 1
[root@localhost ~]# perf record -e probe_libc:malloc -aR sleep 1 perf: Segmentation fault Segmentation fault
perf が Segmentation fault する.
続きを読むこのエントリを書いたのちに kernel-3.10.0-862.3.3.el7.x86_64.rpm がリリースされていますが、 Intel® Core-based microprocessors の Lazy FP state restore の脆弱性 - CVE-2018-3665 を対象としたセキュリティフィックスを含むのみで、↑ のエントリで取り上げたバグは修正されていません
changelog を見ても下記の通り CVE-2018-3665 の fix のみです
%changelog
* Wed Jun 13 2018 Rado Vrbovsky <rvrbovsk@redhat.com> [3.10.0-862.3.3.el7]
- [x86] always enable eager FPU by default on non-AMD processors (Paolo Bonzini) [1589051 1589048] {CVE-2018-3665}
前回のエントリ通り、再現コードを実行して確認をとりました 🔥
CentOS Linux 7 (Core) Kernel 3.10.0-862.3.3.el7.x86_64 on an x86_64 localhost login: [ 377.118566] BUG: unable to handle kernel paging request at 000000000004c200 [ 377.129371] IP: [<ffffffffb77f75f4>] kmem_cache_alloc+0x74/0x1f0 [ 377.137867] PGD 8000000044262067 PUD 55b66067 PMD 0 [ 377.146259] Oops: 0000 [#1] SMP [ 377.148965] Modules linked in: vboxvideo(OE) ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm vboxsf(OE) vboxguest(OE) nls_utf8 isofs loop sunrpc iosf_mbi crc32_pclmul crc32c_intel snd_intel8x0 ghash_clmulni_intel snd_ac97_codec ac97_bus aesni_intel snd_pcm lrw ppdev snd_timer gf128mul sg snd e1000 i2c_piix4 glue_helper ablk_helper soundcore cryptd i2c_core parport_pc parport video pcspkr ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi ata_piix crct10dif_pclmul libata crct10dif_common serio_raw dm_mirror dm_region_hash dm_log dm_mod [ 377.246153] CPU: 1 PID: 28685 Comm: inotify Tainted: G OE ------------ 3.10.0-862.3.3.el7.x86_64 #1 [ 377.282811] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 377.309794] task: ffff9092180caf70 ti: ffff909202318000 task.ti: ffff909202318000 [ 377.588542] RIP: 0010:[<ffffffffb77f75f4>] [<ffffffffb77f75f4>] kmem_cache_alloc+0x74/0x1f0 [ 377.621774] RSP: 0018:ffff90920231be48 EFLAGS: 00010282 [ 377.655148] RAX: 0000000000000000 RBX: ffff909204619a10 RCX: 0000000000006924 [ 377.692181] RDX: 0000000000006923 RSI: 00000000000000d0 RDI: ffff90923907f800 [ 377.698113] RBP: ffff90920231be78 R08: 000000000001cdd0 R09: ffffffffb786316d [ 377.709186] R10: ffff90923cc9bb40 R11: ffffd95580d93200 R12: 000000000004c200 [ 377.719453] R13: 00000000000000d0 R14: ffff90923907f800 R15: ffff90923907f800 [ 377.728466] FS: 00007f14d71c1740(0000) GS:ffff90923cc80000(0000) knlGS:0000000000000000 [ 377.740987] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 377.754305] CR2: 000000000004c200 CR3: 00000000396a0000 CR4: 00000000000606e0 [ 377.766051] Call Trace: [ 377.766776] [<ffffffffb786316d>] ? fsnotify_add_mark_locked+0x12d/0x300 [ 377.772651] [<ffffffffb786316d>] fsnotify_add_mark_locked+0x12d/0x300 [ 377.786170] [<ffffffffb7865137>] SyS_inotify_add_watch+0x2f7/0x370 [ 377.791428] [<ffffffffb7d2082f>] system_call_fastpath+0x1c/0x21 [ 377.802655] [<ffffffffb7d2077b>] ? system_call_after_swapgs+0xc8/0x160 [ 377.809983] Code: 9b 81 48 49 8b 50 08 4d 8b 20 49 8b 40 10 4d 85 e4 0f 84 28 01 00 00 48 85 c0 0f 84 1f 01 00 00 49 63 46 20 48 8d 4a 01 4d 8b 06 <49> 8b 1c 04 4c 89 e0 65 49 0f c7 08 0f 94 c0 84 c0 74 ba 49 63 [ 378.035309] RIP [<ffffffffb77f75f4>] kmem_cache_alloc+0x74/0x1f0 [ 378.086423] RSP <ffff90920231be48> [ 378.122637] CR2: 000000000004c200 [ 378.144306] ---[ end trace 284b8f40714989c1 ]--- [ 378.171508] Kernel panic - not syncing: Fatal exception [ 378.196196] Kernel Offset: 0x36600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
代わりに CentOS Plus の kernel-plus-3.10.0-862.3.3.el7.centos.plus.x86_64.rpm でパッチが当てられて fix されています
0006828: Tracking for centosplus kernels for CentOS-7 - CentOS Bug Tracker
CentOSPlus ってこういうリリースのされ方をするんだな ... 今まで CentOS にお世話になりまくっているのに全然知らずにいました.
加えて、本エントリとはあまり関係ありませんが iotop が動かないバグ の修正も入っています
$ sudo yum install --enablerepo=centosplus kernel-plus
インストール後、reboot してカーネルのバージョンを確認する
$ uname -a Linux localhost.localdomain 3.10.0-862.3.3.el7.centos.plus.x86_64 #1 SMP Fri Jun 15 13:49:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
再現コードを 30分くらい回してみたけど何も起こらなかったので大丈夫 ... なはずです (レースコンデションのバグだとほんとに直ったのかどうか 言い切るの難しいですね). メンテナさんも確認してるから大丈夫だろう
yum install kernel で入る方 ) で修正はいらないかなぁ〜(2018/6/16 14:15 追記) VM を作り直したら systemd が segmentaion fault するもののカーネルパニックは再現しなくなったので、私の VM がおかしかった可能性があります . 中途半端な検証ですいません. 引き続き調べてい ます
Dynamically Obtain Shared Object Library Data with uprobes - Wind River Knowledge Library
ここを参照しながら perf probe と perf record を試していたのだが、 CentOS7.5 - 3.10.0-862.3.2.el7.x86_64 でバグと思われる挙動に遭遇した. 調べている途中だが、記録を書き出す