应限制核心转储文件大小与存放位置、过滤敏感内存段、部署运行时检测机制并采用替代调试方案。具体包括：ulimit -c 控制大小；/proc/sys/kernel/core_pattern 和 /etc/systemd/coredump.conf 配置路径与策略；prctl 和 madvise 排除敏感内存；inotify 或 ebpf 监控异常；改用 systemd-coredump、栈回溯或硬件隔离等轻量调试方式。
系统核心转储（core dump）文件在调试崩溃问题时很有用，但若不限制其生成行为或未过滤敏感内存区域，可能造成隐私泄露、磁盘耗尽甚至被攻击者利用来提取密钥、令牌等关键数据。
限制核心转储文件大小与存放位置
默认情况下，Linux 可能允许生成超大 core 文件（如数 GB），填满根分区。可通过以下方式控制：
- 使用 ulimit -c 设置单个进程允许的最大 core 文件大小（单位 KB），设为 0 表示禁用，设为 unlimited 表示无限制（不推荐）
- 通过 /proc/sys/kernel/core_pattern 指定保存路径和命名规则，建议指向独立小分区（如 /var/crash/），并启用带 PID、时间戳的格式： |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %h %e（交由 coredumpctl 管理更安全）
- 配置 /etc/systemd/coredump.conf 统一管理策略，例如设置 MaxUse=2G、KeepFree=1G 防止磁盘写满
过滤敏感内存段避免泄露
默认 core dump 包含进程全部虚拟内存页，包括堆、栈、VDSO、私有映射区等，其中可能含有密码、JWT、TLS 私钥等。需主动排除：
- 程序启动前调用 prctl(PR_SET_DUMPABLE, 0)，使内核跳过该进程的 core dump（适用于已知含敏据的服务）
- 对特定内存区域使用 madvise(addr, len, MADV_DONTDUMP)，标记不参与 dump（glibc 2.25+ 支持，常用于 malloc 分配后立即标记）
- 内核参数 kernel.core_uses_pid=1 和 fs.suid_dumpable=0 可分别避免覆盖、禁止 setuid 程序生成 core（防止提权后窃取）
运行时检测与自动响应
仅靠静态限制不够，还需监控异常行为：
- 部署 inotify 或 systemd.path 监控 /var/crash/ 或 core_pattern 指向目录，发现新 core 文件立即触发分析脚本
- 用 eu-readelf -l core | grep LOAD 或 gdb -batch -ex 'info proc mappings' -p $(pidof app) 检查是否包含可疑高地址或匿名映射段
- 结合 eBPF 工具（如 bpftrace）捕获 execve + set_dumpable 调用链，在敏感进程启动时自动关闭 dump 能力
替代调试方案降低依赖 core dump
减少对完整 core 的依赖，改用更轻量、可控的方式定位问题：
- 启用 systemd-coredump 并配合 coredumpctl debug，它默认压缩、限大小、支持符号分离，且可配置 ProcessSizeMax=50M
- 在关键服务中集成 libbacktrace 或 abrt-hook，发生 SIGSEGV 时只保存栈回溯 + 寄存器状态，不落地完整内存
- 对加密模块等核心组件，使用硬件支持的 Intel SGX 或 ARM Memory Tagging Extension 隔离敏感数据，使其天然不可被 dump 访问
