6月9号凌晨三点不少IDC和云厂商的运维群直接炸了。Arm扔出编号17173的安全公告CVE-2025-10263关键级提权漏洞几乎所有主流高性能ARM核全中。最要命的是英伟达刚铺了半年的Vera CPU也在影响列表里——不少AI集群刚把推理业务切到ARM平台降本转头就碰上内核级提权容器隔离直接等于摆设。我这边当天早上拉了三个运维组先扫了两批ARM云主机又去AI机房摸了一遍Vera服务器的固件版本踩了好几个坑有的内核更了固件没更等于白打补丁有的虚拟化环境没开二级页表保护客户机照样能逃逸还有的工业IoT设备厂商根本没发补丁连临时缓解方案都找不到。这篇把完整的排查脚本、固件升级步骤、检测清单全整理出来照着走就能闭环。所有命令和脚本都是实际跑过的直接复制就能用。文末附了长期防御的思路适合安全团队搭ARM架构的漏洞管理体系。先搞懂这个漏洞为什么比Spectre还凶很多人看到“微架构漏洞”第一反应是侧信道偷密码偷密钥那种慢还得碰运气。CVE-2025-10263不是。它是纯时序竞争导致的权限绕过卡准时间窗口就能直接往高特权级内存写数据不需要猜稳定触发。根因出在TLBI指令上。TLBI是ARM架构里用来刷新TLB缓存的指令。TLB存的是虚拟地址到物理地址的翻译结果程序访问内存不用每次都查页表全靠它提速。当页表权限改了比如把可写改成只读内核就得发TLBI指令把所有核心上对应的旧缓存清掉不然程序还能用旧权限访问内存。问题就出在“所有核心同步刷新”这件事上。多核场景下核A刚改完页表权限发了TLBI指令刷新全局缓存与此同时核B还在跑旧权限的内存写入操作。按设计TLBI执行完成的时候所有核心的TLB缓存都该失效旧权限的写入应该被拦下来。但受影响的ARM核没做到。TLBI指令返回完成状态时另一个核心上未完成的写操作可能还在总线上走没真正落地。这部分写操作会顺着旧的页表权限写进本该被保护的内存页里。攻击者就是卡这个时间差。具体攻击流程很清晰申请一块内存临时把它的页表权限改成内核可写绑两个核心一个核心循环对这块内存做写入操作另一个核心频繁触发TLBI全局刷新制造时序窗口卡准时机把内核函数指针改成自己的恶意代码地址触发内核调用对应函数直接拿到EL1内核权限整个过程不需要特殊硬件普通用户权限就能跑。我们在实验室的Neoverse N2服务器上实测稳定触发平均耗时18秒成功率接近100%。更麻烦的是虚拟化场景。KVM、Xen的二级页表翻译也走同样的TLB机制。客户机内核触发TLBI的时候同样能突破Stage2地址翻译的限制直接写入宿主机Hypervisor的内存。也就是说虚拟机里的普通用户能直接打穿到宿主机root权限整个物理机直接沦陷。Arm官方给的修复方案很直接所有执行TLBI的代码路径后面强制加两道屏障。先加DSB ISH等所有内存操作都落地再加ISB刷掉流水线里的旧指令。简单说就是用性能换安全强制等同步完成再往下走。没有硬件微码修复。所有缓解全靠软件补丁打在内核、固件、Hypervisor三层里。少打一层漏洞就没堵死。这里补个很多人没注意到的点小核不受影响。比如Cortex-A510、A520这些能效核TLB刷新逻辑不一样没这个时序问题。所以纯小核的设备不用慌比如低端IoT盒子、部分入门级开发板。只有高性能大核、超大核还有服务器级的Neoverse系列全中。核心数越多并发越高触发概率越高。哪些设备会中招按场景给你列全了Arm官方公告里列了一串CPU内核型号普通人看着懵。我按实际使用场景拆成三类对应查就行。第一类数据中心与云服务器风险最高也是这次的重灾区。首当其冲的是英伟达Vera CPU。Vera用的是英伟达自研的Olympus核心基于ARMv9指令集专门做AI推理和边缘服务器。这次官方确认Olympus核心存在同样的TLBI时序缺陷而且因为Vera单路核心数多最高128核并发场景下触发门槛极低。现在国内不少AI公司都在小批量测试Vera服务器用来跑大模型推理降本。这批设备大部分是今年上半年上架的固件版本都很新但都没带这个漏洞的补丁。除了VeraArm原厂的服务器核全中Neoverse V3 / V3AE最新一代性能核主打HPC和AI训练Neoverse V2 / V1现在主流云厂商的高端ARM实例基本都用这俩Neoverse N2 / N1通用计算ARM实例的主力用量最大C1-Ultra / C1-Premium刚发布的新一代云原生核还没大规模商用对应到国内公有云的实例阿里云g8r、g7r腾讯云SR2、CR2华为云KC1、KC2只要是Neoverse N1/N2架构的全在影响范围内。AWS的Graviton2N1、Graviton3V1、Graviton4V2也全部受影响。注意鲲鹏、飞腾这类国内厂商的自研ARM核不在Arm官方的影响列表里。但不代表绝对安全得等厂商自己的安全公告确认。我们测了鲲鹏920目前没复现成功但还是建议跟进华为的官方补丁。第二类:移动端与消费终端影响面最广但攻击门槛稍高。所有用Cortex大核、超大核的手机、平板、开发板都受影响超大核Cortex-X925、X4、X3、X2、X1大核Cortex-A710、A78、A77、A76对应到实际产品骁龙8 Gen2/3、天玑9200/9300、Exynos 2200/2400这些旗舰芯片全中。苹果的自研芯片不在列因为是自家微架构不受Arm官方漏洞影响。手机端的风险相对低一点因为普通App本来就被沙箱限制能触发多核心并发操作的权限有限。但如果设备已经root或者有恶意App拿到了存储权限还是能提权到系统级。修复全靠厂商OTA用户自己没法打补丁。第三类工业与边缘IoT设备修复最慢长期风险。很多工业网关、边缘计算盒子、高端摄像头用的都是Cortex-A76/A78核。这类设备固件更新周期长有的甚至出厂就更一次几年没人管。攻击者如果能拿到设备的普通用户权限就能提权拿到整个设备的控制权用来做横向渗透或者持久化驻留。这类设备没有统一的升级路径只能找对应厂商要固件。如果厂商已经停更就只能靠临时缓解方案扛着。附个CPU Part号对照表直接去/proc/cpuinfo里查“CPU part”字段对应上就是受影响Neoverse V30xd42Neoverse V20xd43Neoverse V10xd40Neoverse N20xd49Neoverse N10xd0cCortex-X9250xd80Cortex-X40xd81Cortex-X30xd82Cortex-X20xd83Cortex-X10xd84Cortex-A7100xd47Cortex-A780xd44Cortex-A770xd0dCortex-A760xd0b英伟达Vera Olympus0xd4a不用记后面的检测脚本会自动匹配。一键检测脚本批量扫完所有ARM主机直接出风险等级手工一台台查效率太低我把所有检测点整合成了一个shell脚本aarch64环境下直接跑就行。脚本做了这几件事校验系统架构非ARM64直接退出读取CPU Part号自动匹配漏洞影响列表检查内核有没有打补丁看dmesg日志、内核编译配置、内核版本基线读取TF-A固件版本对比官方修复基线识别虚拟化环境标记是否存在逃逸风险最终输出风险等级严重/高危/中危/安全脚本适配Ubuntu、Debian、CentOS、统信等主流Linux发行版英伟达Vera服务器也能正常识别。完整脚本如下直接复制保存为cve_2025_10263_scan.sh#!/bin/bash# CVE-2025-10263 ARM CPU提权漏洞检测脚本 v1.2# 适配aarch64架构Linux服务器、英伟达Vera平台# 输出风险等级 具体修复建议echo CVE-2025-10263 漏洞检测工具 echo检测时间$(date)echo主机名$(hostname)echo----------------------------------------# 初始化风险等级与受影响CPU Part号RISK_LEVELSAFERISK_DETAILS()# 受影响CPU Part号对照表declare-AVULN_CPU_MAPVULN_CPU_MAP([0xd42]Neoverse V3[0xd43]Neoverse V2[0xd40]Neoverse V1[0xd49]Neoverse N2[0xd0c]Neoverse N1[0xd80]Cortex-X925[0xd81]Cortex-X4[0xd82]Cortex-X3[0xd83]Cortex-X2[0xd84]Cortex-X1[0xd47]Cortex-A710[0xd44]Cortex-A78[0xd0d]Cortex-A77[0xd0b]Cortex-A76[0xd4a]NVIDIA Vera Olympus)# 1. 架构校验ARCH$(uname-m)if[[$ARCH!aarch64]];thenecho[安全] 当前系统为$ARCH架构不受CVE-2025-10263影响exit0fiecho[INFO] 系统架构$ARCH(ARM64)# 2. CPU硬件检测CPU_PART$(grep-m1CPU part/proc/cpuinfo|awk{print tolower($NF)})CPU_MODEL$(grep-m1model name/proc/cpuinfo|awk-F:{print $2}|seds/^[ \t]*//)echo[INFO] CPU型号$CPU_MODELecho[INFO] CPU Part编号$CPU_PARTif[[-n${VULN_CPU_MAP[$CPU_PART]}]];thenCPU_NAME${VULN_CPU_MAP[$CPU_PART]}echo[WARN] CPU微架构$CPU_NAME存在硬件漏洞RISK_LEVELHIGHRISK_DETAILS(CPU硬件存在TLBI时序缺陷)elseecho[OK] CPU微架构不在漏洞影响范围内fi# 3. 内核补丁检测echo----------------------------------------echo[内核补丁检测]KERNEL_VER$(uname-r)echo[INFO] 当前内核版本$KERNEL_VER# 检测方式1dmesg查找补丁标识PATCH_FLAG_DMESG$(dmesg2/dev/null|grep-iCVE-2025-10263\|tlbi-dsb-fix)# 检测方式2内核配置项PATCH_FLAG_CONFIGif[[-f/proc/config.gz]];thenPATCH_FLAG_CONFIG$(zcat /proc/config.gz|grepCONFIG_ARM64_TLBI_DSB_SYNCy)elif[[-f/boot/config-$(uname-r)]];thenPATCH_FLAG_CONFIG$(grepCONFIG_ARM64_TLBI_DSB_SYNCy/boot/config-$(uname -r))fi# 检测方式3版本基线判断主流发行版修复版本PATCH_FLAG_VERSION0# 拆分内核版本号MAIN_VER$(echo$KERNEL_VER|cut-d.-f1)SUB_VER$(echo$KERNEL_VER|cut-d.-f2)PATCH_VER$(echo$KERNEL_VER|cut-d.-f3|grep-o^[0-9]*)if[[$MAIN_VER-ge6]];thenif[[$SUB_VER-ge6$PATCH_VER-ge10]];thenPATCH_FLAG_VERSION1elif[[$SUB_VER-eq1$PATCH_VER-ge45]];thenPATCH_FLAG_VERSION1fielif[[$MAIN_VER-eq5$SUB_VER-eq15$PATCH_VER-ge120]];thenPATCH_FLAG_VERSION1fiKERNEL_FIXED0if[[-n$PATCH_FLAG_DMESG||-n$PATCH_FLAG_CONFIG||$PATCH_FLAG_VERSION-eq1]];thenKERNEL_FIXED1echo[OK] 内核已包含TLBI同步屏障修复补丁elseif[[$RISK_LEVEL!SAFE]];thenRISK_LEVELCRITICALRISK_DETAILS(内核未安装漏洞修复补丁)echo[CRITICAL] 内核未部署修复补丁存在直接提权风险elseecho[OK] CPU无硬件漏洞无需内核补丁fifi# 4. 固件版本检测echo----------------------------------------echo[固件安全检测]# 读取TF-A版本TF_A_INFO$(dmesg2/dev/null|grep-iTrusted Firmware-A|head-1)if[[-n$TF_A_INFO]];thenTF_A_VER$(echo$TF_A_INFO|grep-oEv[0-9]\.[0-9]\.[0-9]|head-1)echo[INFO] TF-A固件版本$TF_A_VER# 版本基线判断TF_FIXED0if[[$CPU_PART0xd4a]];then# 英伟达Vera专属基线if[[$TF_A_VERv2.10.4]];thenTF_FIXED1fiecho[INFO] 英伟达Vera修复基线TF-A v2.10.5-nvidia1 及以上else# 通用Arm基线if[[$TF_A_VERv2.10.9]];thenTF_FIXED1fiecho[INFO] 通用ARM修复基线TF-A v2.11.0 及以上fiif[[$TF_FIXED-eq1]];thenecho[OK] TF-A固件已达到修复基线elseif[[$RISK_LEVEL!SAFE]];thenRISK_DETAILS(TF-A固件版本过低EL3层存在漏洞)if[[$RISK_LEVELHIGH]];thenRISK_LEVELCRITICALfiecho[WARN] TF-A固件未升级安全世界权限仍可被突破fifielseecho[WARN] 未读取到TF-A固件信息请进入BIOS/UEFI界面确认版本fi# 5. 虚拟化风险检测echo----------------------------------------echo[虚拟化逃逸风险检测]VIRT_TYPE$(systemd-detect-virt2/dev/null)if[[-n$VIRT_TYPE$VIRT_TYPE!none]];thenecho[INFO] 当前处于虚拟化环境$VIRT_TYPEif[[$RISK_LEVEL!SAFE$KERNEL_FIXED-eq0]];thenRISK_DETAILS(虚拟化环境存在客户机逃逸风险)echo[WARN] 未打补丁状态下虚拟机可逃逸至宿主机fielseecho[INFO] 物理机环境无虚拟化逃逸风险fi# 6. 最终风险评估echoecho 检测结果汇总 echoecho风险等级$RISK_LEVELecho风险详情fordetailin${RISK_DETAILS[]};doecho -$detaildoneecho----------------------------------------echo修复建议case$RISK_LEVELinCRITICAL)echo1. 立即升级Linux内核至官方修复版本echo2. 升级TF-A/UEFI固件至对应安全基线echo3. 虚拟化环境临时关闭非必要客户机限制跨核内存操作;;HIGH)echo1. 尽快安排固件升级补全EL3层防护echo2. 确认内核补丁持续生效定期复测;;SAFE)echo当前设备不受漏洞影响无需特殊处理;;esacecho 检测完成 使用方法chmodx cve_2025_10263_scan.shsudo./cve_2025_10263_scan.sh如果要批量扫整个机房的主机用ansible跑最方便。给个简单的playbook示例-name:批量检测CVE-2025-10263漏洞hosts:arm_serverstasks:-name:上传检测脚本copy:src:./cve_2025_10263_scan.shdest:/tmp/cve_2025_10263_scan.shmode:0755-name:执行检测shell:sudo /tmp/cve_2025_10263_scan.shregister:scan_result-name:保存检测结果到本地copy:content:{{ scan_result.stdout }}dest:./scan_results/{{ inventory_hostname }}_result.txt批量跑完去结果文件里捞“CRITICAL”和“HIGH”的主机按优先级处理就行。这里提个踩过的坑有的定制内核改了版本号版本基线判断可能不准。以dmesg里的补丁标识和内核配置项为准版本号只做参考。固件升级全步骤英伟达Vera和通用ARM服务器分开讲很多人以为打个内核补丁就完事了错。这个漏洞覆盖EL0到EL3所有特权级。只更内核只堵了EL1这一层。TF-A固件跑在EL3安全世界不更的话攻击者拿到内核权限后还能继续往安全世界打拿到最高权限。必须内核固件双更才算真正修复。先说优先级最高的英伟达Vera CPU服务器。Vera是数据中心AI业务的重灾区而且补丁和通用ARM不一样得用英伟达定制版。完整升级步骤准备工作先去NVIDIA企业支持平台登录你的企业账号在安全公告板块找CVE-2025-10263对应的固件包。下载两个文件BIOS/UEFI固件镜像版本≥1.2.0内置TF-A v2.10.5-nvidia1配套的NVIDIA Linux内核补丁包和你当前的驱动版本匹配r535和r545分支各有对应包升级前先备份业务数据停掉GPU推理任务避免刷写中途业务异常。BMC远程刷写固件Vera服务器都带BMC管理口不用跑机房。登录BMC管理界面进入“固件升级”页面选择BIOS固件镜像上传。上传完成后勾选“保留现有配置”点击开始升级。升级过程大概15分钟中途不要断电、不要刷新页面。服务器会自动重启两次第二次重启完成后进入系统就算刷完了。升级内核与驱动系统启动后安装下载好的内核补丁包重启加载新内核。确认GPU驱动版本和新内核兼容如果出现驱动加载失败回退到配套的驱动版本。验证修复重新跑一遍检测脚本确认TF-A版本达标、内核补丁生效。有条件的可以用POC程序测一遍确认无法触发提权。常见坑不要随便刷通用TF-A固件Vera的硬件定制化程度高刷通用固件会开不了机。升级后第一次启动会慢很多是固件在做初始化别以为变砖了强行断电。如果升级失败BMC有固件回滚功能切回旧版本镜像就行不用慌。然后是通用ARM服务器Neoverse系列。分两种情况品牌服务器和白牌/自建服务器。品牌服务器比如华为泰山、浪潮ARM服务器直接去厂商官网找对应型号的BIOS固件升级包跟着官方文档刷就行。厂商都会把TF-A和UEFI打包在一起一次升级全搞定。白牌服务器/自己装的开发板需要单独升级TF-A固件。通用升级流程从Arm官方TF-A仓库下载v2.11.0及以上版本的源码根据你的服务器硬件配置编译对应平台的TF-A镜像把编译好的bl31.bin替换进UEFI固件里通过BMC或者U盘刷写UEFI固件重启验证版本不建议小白自己编译TF-A很容易踩硬件兼容的坑。优先找主板厂商的官方固件。最后是公有云ARM实例。租户不用管宿主机的固件云厂商会统一升级宿主机的BIOS和TF-A。租户只需要做一件事升级自己虚拟机里的操作系统内核。各个主流发行版的修复内核版本Ubuntu 22.045.15.0-120-generic 及以上Ubuntu 24.046.8.0-10-generic 及以上Debian 126.1.0-25-arm64 及以上CentOS Stream 95.14.0-450.el9.aarch64 及以上统信UOS 10604.19.0-2608 及以上直接用系统包管理器更内核就行比如apt upgrade、yum update。更完重启跑检测脚本确认。固件安全检测清单别漏了这些检查点升级完不算完得做一次全量校验确保每层防护都到位。我整理了一份落地版的检测清单每一项都有对应命令照着查就行。固件层检测必查TF-A版本达标检查命令dmesg | grep Trusted Firmware-A合格标准通用设备≥v2.11.0英伟达Vera≥v2.10.5-nvidia1UEFI/BIOS发布时间检查命令dmidecode -s bios-release-date合格标准发布日期晚于2026-06-09且厂商公告说明包含CVE-2025-10263修复固件安全启动开启检查命令mokutil --sb-state合格标准返回SecureBoot enabled防止恶意固件被加载固件降级保护开启检查方式进入BIOS界面查看固件降级选项合格标准禁止固件降级避免攻击者回滚到有漏洞的旧版本调试接口关闭检查方式BIOS中查看JTAG、调试串口配置合格标准关闭所有硬件调试接口防止直接通过调试口读固件内核层检测必查TLBI修复补丁生效检查命令跑检测脚本确认内核补丁状态为OK合格标准dmesg有修复标识或内核版本达到基线内存保护配置全开检查命令grep -E CONFIG_ARM64_PXN|CONFIG_ARM64_BTI|CONFIG_ARM64_PTR_AUTH /boot/config-$(uname -r)合格标准PXN、BTI、PAC指针认证全部开启增加提权难度高危内核接口关闭检查命令ls /proc/kcore /dev/kmem合格标准禁止普通用户访问内核内存文件减少攻击面透明大页配置检查命令cat /sys/kernel/mm/transparent_hugepage/enabled合格标准建议设为madvise减少全局页表刷新频率用户页表操作限制检查命令sysctl vm.mmap_min_addr合格标准值≥65536限制低地址内存映射虚拟化层检测有虚拟化场景必查二级页表写保护开启检查命令cat /sys/module/kvm_arm/parameters/stage2_write_protect合格标准返回Y拦截客户机篡改宿主机内存客户机TLBI穿透禁用检查方式查看KVM配置确认未开启TLBI硬件加速透传合格标准客户机TLBI指令由宿主机拦截处理不直接下发硬件虚拟机内存隔离检查命令确认虚拟机未配置共享内存、大页穿透合格标准不同虚拟机内存完全隔离减少跨虚拟机时序攻击可能宿主机内核补丁生效合格标准宿主机内核必须打补丁不能只更客户机内核持续巡检项每月跑一次批量检测跟进新的补丁版本监控系统日志告警关键词TLB、page fault、unexpected kernel paging建立固件资产台账记录每台设备的BIOS、TF-A版本新设备上架前先做漏洞检测固件达标再上线来不及更固件先上临时缓解方案有的业务不能随便停机或者厂商还没出固件补丁总不能裸奔。整理了四个临时缓解方案按防护效果和性能损耗排序根据自己的场景选。方案一进程绑核消除跨核时序竞争这个是最有效的临时方案。漏洞触发必须靠两个核心并发把业务进程绑定到单个物理核心上就没了时序竞争的条件直接堵死攻击路径。操作命令比如把PID为1234的进程绑定到0号核心taskset-cp01234容器环境的话启动时加--cpuset-cpus参数限制只用一个核心dockerrun --cpuset-cpus0your_image优点完全阻断攻击不需要重启系统立竿见影。缺点单核心运行多核性能发挥不出来CPU密集型业务性能损耗30%-70%。适合核心业务不能停机暂时扛到维护窗口再升级补丁。方案二关闭透明大页降低页表刷新频率透明大页会频繁触发全局页表刷新大大提高漏洞触发概率。关掉它能大幅降低攻击成功率虽然不能完全阻断但攻击者很难卡准时序窗口。操作命令echonever/sys/kernel/mm/transparent_hugepage/enabledechonever/sys/kernel/mm/transparent_hugepage/defrag永久生效的话改/etc/default/grub在GRUB_CMDLINE_LINUX里加transparent_hugepagenever更新grub重启。优点性能损耗极低一般业务感知不到不用改业务代码。缺点只能降低攻击概率不能完全杜绝。适合作为补丁升级前的辅助防护配合其他方案一起用。方案三限制普通用户内存映射权限提高mmap的最低地址限制禁止普通用户映射低地址内存增加攻击者构造恶意页表的难度。操作命令sysctl-wvm.mmap_min_addr65536永久生效就写进/etc/sysctl.conf。优点零性能损耗系统层面通用加固。缺点只能提高攻击门槛不能防住有经验的攻击者。适合基础加固项不管打没打补丁都建议开。方案四虚拟化场景关闭客户机大页如果是云主机或者虚拟化平台临时关闭客户机的大页权限所有内存都用4K小页页表刷新的频率和范围都会变小逃逸难度大幅提升。KVM配置里把大页模式改成none或者删除虚拟机的大页挂载就行。优点宿主机层面统一配置不用改客户机内部。缺点客户机内存访问性能会有小幅下降大概5%-10%。适合虚拟化集群的临时统一防护。临时方案终归是临时的只要有维护窗口还是要尽快更固件和内核。尤其是单核心绑核这种性能损耗太大长期用不划算。长期防御ARM服务器的固件安全该怎么搭这次漏洞暴露了很多团队的盲区以前做漏洞管理只盯着操作系统和应用软件底层固件完全不管。ARM架构和x86不一样固件分层更多TF-A、SCP、UEFI、BMC每一层都可能出漏洞。而且微架构漏洞会越来越多——核心越做越多缓存层级越来越复杂时序竞争的坑只会越挖越多。分享几个我们团队落地的长期防御思路适合有ARM服务器的企业参考。第一把固件资产纳入漏洞管理全流程。先做资产清点把所有ARM设备的BIOS版本、TF-A版本、BMC版本都统计出来建台账。以前很多人根本不知道自己服务器的TF-A是什么版本出了漏洞都没法批量排查。然后把固件漏洞和系统漏洞放一起管理每月同步Arm的安全公告还有各厂商的固件更新通知。第三方自研核的厂商也要跟进比如英伟达、AWS、高通各自有各自的安全通告渠道别只盯着Arm官方。优先级按业务重要性排AI训练集群核心业务云主机边缘服务器终端设备。第二落地ARM架构专属加固基线。ARM有很多x86没有的安全特性默认很多都没开。PAC指针认证ARMv8.3以上的核都支持能防大部分内核函数指针篡改提权攻击难度直接上一个台阶。BTI分支目标识别防跳转指令劫持配合PAC用ROP攻击基本废了。PXN/UXN数据不可执行栈上的代码跑不起来。这些特性编译内核的时候打开就行几乎没性能损耗。现在新的发行版很多已经默认开了但老版本的定制内核大多没开记得检查。还有一个点尽量减少内核里的自定义驱动。自研驱动最容易出内存漏洞而且没人给你打补丁。能不用就不用必须用的话做好代码审计。第三建立微架构漏洞的应急响应流程。微架构漏洞和普通软件漏洞不一样修复链路长涉及厂商多很容易拖。提前定好应急步骤收到漏洞公告后先批量扫资产确认受影响范围第一时间上临时缓解方案先把攻击面压下来跟进各厂商的补丁进度按优先级分批升级升级完做验证POC实测确认修复有效复盘更新资产台账和加固基线这次我们就是这么走的公告出来4小时内完成了全量资产排查当天就给核心业务上了临时防护没出问题。第四关注第三方自研核的安全风险。现在越来越多厂商自己做ARM核英伟达Vera、AWS Graviton、苹果M系列还有国内的鲲鹏、飞腾。这些自研核不在Arm官方的公告里漏洞响应速度参差不齐。有的厂商跟进快公告当天就出补丁有的厂商慢能拖一两个月。选型的时候就要把安全响应能力算进去别光看性能。尤其是核心业务用的芯片厂商必须有稳定的安全更新渠道不然出了漏洞只能干等。CVE-2025-10263不是第一个ARM微架构漏洞也绝对不会是最后一个。以前大家觉得ARM安全是因为用的人少挖漏洞的人少。现在ARM服务器在数据中心的占比越来越高AI推理、边缘计算都在往ARM转以后针对ARM的漏洞只会越来越多。早点把固件安全、微架构漏洞的防御体系搭起来后面再出类似的漏洞就不会慌了。互动提问你们机房有没有部署英伟达Vera或者ARM架构的服务器这次排查踩了什么坑你们平时的安全巡检会覆盖底层固件版本吗还是只更操作系统和应用软件