6月の中旬にSymantec Endpoint Protection(SEP)の14.2がリリースされたので早速AWS環境のRHEL7.4へインストールしてみたところ問題なく動作。symap、symevのカーネルモジュールも14.2同梱のモジュールで動作するのでカーネルモジュールのコンパイル環境も不要。…とここまではいいのだけど、SEP14.2がインストールされた環境を7.5に更新するとSEPの不具合が発生してシステムにログイン(ssh接続)できなくなる事象を確認（再現率100 %）。RHEL7.5へのSEP14.2インストール不具合と同じ要因と考えられるが、あちらはSEPインストール途中でシステムクラッシュが発生してOS強制再起動となるがSEPはインストールされないのログインできなくなることは無いのでダメージはこちらのほうが大きい。
AWSのコンソールからシステムログを確認すると
[ 9.568009] symev_rh_ES_7_3_10_0_693_el7_x86_64: loading out-of-tree module taints kernel. [ 9.575077] WARNING: module 'symev_rh_ES_7_3_10_0_693_el7_x86_64' built without retpoline-enabled compiler, may affect Spectre v2 mitigation [ 9.624387] symev_rh_ES_7_3_10_0_693_el7_x86_64: module verification failed: signature and/or required key missing - tainting kernel [ 10.181262] BUG: unable to handle kernel paging request at ffffffffac803310 [ 10.182058] IP: [<ffffffffc04ff3bd>] symev_hook_syscalls+0x2d/0xf60 [symev_rh_ES_7_3_10_0_693_el7_x86_64] [ 10.182058] PGD 4f812067 PUD 4f813063 PMD 800000004f4000e1 [ 10.182058] Oops: 0003 [#1] SMP [ 10.182058] Modules linked in: symev_rh_ES_7_3_10_0_693_el7_x86_64(OE+) isofs sb_edac intel_rapl iosf_mbi crc32_pclmul ghash_clmulni_intel cirrus ttm drm_kms_helper syscopyarea aesni_intel sysfillrect sysimgblt fb_sys_fops lrw gf128mul drm glue_helper ablk_helper ppdev cryptd i2c_piix4 pcspkr i2c_core parport_pc parport ip_tables xfs libcrc32c ata_generic pata_acpi ata_piix libata xen_netfront crct10dif_pclmul crct10dif_common xen_blkfront crc32c_intel serio_raw floppy [ 10.182058] CPU: 0 PID: 1101 Comm: insmod Tainted: G OE ------------ 3.10.0-862.9.1.el7.x86_64 #1 [ 10.182058] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006 [ 10.182058] task: ffffa04cfb3ccf10 ti: ffffa04cfaa44000 task.ti: ffffa04cfaa44000 [ 10.182058] RIP: 0010:[<ffffffffc04ff3bd>] [<ffffffffc04ff3bd>] symev_hook_syscalls+0x2d/0xf60 [symev_rh_ES_7_3_10_0_693_el7_x86_64] [ 10.182058] RSP: 0018:ffffa04cfaa47d18 EFLAGS: 00010286 [ 10.182058] RAX: ffffffffac803300 RBX: ffffffffacc16020 RCX: ffffffffac803300 [ 10.182058] RDX: 0000000000000000 RSI: ffffffffacca8498 RDI: ffffffffad2001e0 [ 10.182058] RBP: ffffa04cfaa47d18 R08: 0000000000000000 R09: 0000000000000002 [ 10.182058] R10: ffffa04cfd21bd60 R11: ffffeebe40001600 R12: ffffa04cfa162d00 [ 10.182058] R13: ffffffffc05018c0 R14: 0000000000000000 R15: ffffffffc050f0c0 [ 10.182058] FS: 00007fc91487c740(0000) GS:ffffa04cfd200000(0000) knlGS:0000000000000000 [ 10.182058] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 10.182058] CR2: ffffffffac803310 CR3: 000000007b2fc000 CR4: 00000000001606f0 [ 10.182058] Call Trace: [ 10.182058] [<ffffffffc050196d>] init_module+0xad/0x2b0 [symev_rh_ES_7_3_10_0_693_el7_x86_64] [ 10.182058] [<ffffffffac00210a>] do_one_initcall+0xba/0x240 [ 10.182058] [<ffffffffac10fd9c>] load_module+0x272c/0x2bc0 [ 10.182058] [<ffffffffac377250>] ? ddebug_proc_write+0xf0/0xf0 [ 10.182058] [<ffffffffac10b9d3>] ? copy_module_from_fd.isra.43+0x53/0x150 [ 10.182058] [<ffffffffac1103e6>] SyS_finit_module+0xa6/0xd0 [ 10.182058] [<ffffffffac720795>] system_call_fastpath+0x1c/0x21 [ 10.182058] Code: 44 00 00 48 8b 05 2c 01 01 00 55 48 89 e5 48 8b 50 10 48 89 c1 48 85 d2 0f 84 20 03 00 00 48 89 15 09 00 01 00 8b 15 13 01 01 00 <48> c7 40 10 c0 29 50 c0 85 d2 89 d6 0f 8f f5 0e 00 00 48 8b b8 [ 10.182058] RIP [<ffffffffc04ff3bd>] symev_hook_syscalls+0x2d/0xf60 [symev_rh_ES_7_3_10_0_693_el7_x86_64] [ 10.182058] RSP <ffffa04cfaa47d18> [ 10.182058] CR2: ffffffffac803310 [ 10.182058] ---[ end trace c80a4a2b0285bb18 ]--- [ 10.182058] Kernel panic - not syncing: Fatal exception
OS起動時のsymev(SEPのカーネルモジュール)のロードでカーネルパニックとなってる模様。カーネルの更新があった場合、カーネルにマッチしないカーネルモジュール(symev,symap)はロードに失敗してOSが起動されるのが正常な動作。カーネルモジュールがロードされていないSEPはAuto-Protectが無効になっているので注意。SEPの再インストール＆カーネルモジュールのコンパイルによりカーネルにマッチしたカーネルモジュールが作成、ロードされAuto-Protectが動作するようになる。今回のケースは中途半端にカーネルとマッチしたモジュールとなったためロード時にOSを巻き込んでクラッシュしたのかな？ カーネルモジュールの不具合の破壊力は一味違いますなあ。
うっかり7.5へ更新してしまった場合、AWS環境はOSにsshログインできないと単独の復旧方法は無いので
1. EBS修復用のインスタンス起動(Amazon LinuxがXFSに対応してるので無難かも)
2. EBSをデタッチ
3. 修復用インスタンスにEBSをアタッチ
4. アタッチしたEBSの/opt/SymantecディレクトリをリネームしてOS起動時にSEPが起動しないようにする
5. EBSをデタッチして元のインスタンスにアタッチしてOS起動
6. /opt/Symantecを元に戻してSEPのアンインストール(install.sh -u)実施
が今のトコ一番現実的な復帰方法かなあ。
＊オンプレ版のRHELでは試していないのでAWS環境のみの不具合の可能性アリ。
