hook对应的汇编码0x8B, 0xFF,0x55,0x8B, 0xEC, // mov ebp,esp

篡改UnhandledExceptionFilter
本文介绍了一种通过篡改 SetUnhandledExceptionFilter 函数实现的方法,该方法能够在 Windows 系统中修改异常处理流程,实现特定的内存保护或调试目的。
void lockUnhandledExceptionFilter() {
    HMODULE kernel32 = LoadLibraryA("kernel32.dll");
    Assert(kernel32);

    if (FARPROC gpaSetUnhandledExceptionFilter = GetProcAddress(kernel32, "SetUnhandledExceptionFilter")) {
        unsigned char expected_code[] = {
            0x8B, 0xFF, // mov edi,edi
            0x55,       // push ebp
            0x8B, 0xEC, // mov ebp,esp
        };

        // only replace code we expect
        if (memcmp(expected_code, gpaSetUnhandledExceptionFilter, sizeof(expected_code)) == 0) {
            unsigned char new_code[] = {
                0x33, 0xC0,       // xor eax,eax
                0xC2, 0x04, 0x00, // ret 4
            };

            BOOST_STATIC_ASSERT(sizeof(expected_code) == sizeof(new_code));

            DWORD old_protect;
            if (VirtualProtect(gpaSetUnhandledExceptionFilter, sizeof(new_code), PAGE_EXECUTE_READWRITE, &old_protect)) {
                CopyMemory(gpaSetUnhandledExceptionFilter, new_code, sizeof(new_code));

                DWORD dummy;
                VirtualProtect(gpaSetUnhandledExceptionFilter, sizeof(new_code), old_protect, &dummy);

                FlushInstructionCache(GetCurrentProcess(), gpaSetUnhandledExceptionFilter, sizeof(new_code));
            }
        }
    }
    FreeLibrary(kernel32);
}
<think>嗯,用户给了一个关于内核内存分配和OverlayFS的问题。看起来是某个性能分析工具的输出,比如ftrace或者perf,显示两个调用堆栈,次数分别是1次和652次,涉及页面分配和slab分配。 首先,我需要理解每个函数的作用。比如post_alloc_hook和prep_new_page属于内存分配的后期处理,可能检查新分配的页面。get_page_from_freelist是从空闲列表获取页,__alloc_pages_nodemask是底层页分配函数。alloc_slab_page和new_slab是slab分配器的一部分,用于管理内核对象。__kmalloc是内核内存分配函数,接着是d_alloc系列函数,属于dentry缓存分配,最后是OverlayFS的创建流程,比如ovl_create_or_link。 然后,用户提供的两个堆栈结构相同,但次数不同。652次可能意味着频繁的内存分配,可能在文件系统操作中有大量dentry创建。需要分析是否正常,或者是否存在内存泄漏或性能问题。比如OverlayFS在创建文件时频繁分配dentry,或者存在路径查找的重复操作。 可能需要建议用户检查文件系统操作频率,确认是否预期行为,或者使用工具如slabtop查看slab使用情况,检查内存泄漏。另外,PID为-1可能表示进程上下文不重要,或是内核线程。需要进一步的信息,比如系统负载、具体应用场景等。 需要确保回答结构清晰,分点解释每个函数,然后分析可能的原因和建议。同时注意使用中文,符合格式要求,数学表达式用$...$,但这里可能不需要。需要验证LaTeX语法正确,但当前内容可能不涉及复杂公式,主要注意代块和函数名的格式。</think>以下是对该内存分配调用链的逐步分析: $$调用链结构:$$ 1. **内存分配核心路径** - `post_alloc_hook+0x20/0x2c`:内存页分配后的完整性检查钩子函数 - `prep_new_page+0x24/0x74`:初始化新分配的物理内存页 - `get_page_from_freelist+0x34c/0x838`:从空闲列表获取可用内存页 - `__alloc_pages_nodemask+0x144/0x1d8`:NUMA节点感知的内存页分配核心函数 2. **slab分配器路径** - `alloc_slab_page+0x3c/0x240`:为slab分配新的内存页 - `new_slab+0xec/0x248`:创建新的slab对象池 - `___slab_alloc.isra.0.constprop.0+0x140/0x2e4`:slab分配器的慢路径 - `__kmalloc+0xb4/0x144`:内核内存分配通用接口 3. **文件系统相关路径** - `__d_alloc` → `d_alloc` → `d_alloc_parallel`:目录项(dentry)缓存分配 - `lookup_one_len` → `ovl_create_or_link`:OverlayFS文件创建操作 $$差异分析:$$ | 特征 | 第一次调用(1次) | 第二次调用(652次) | |-----------|------------------|------------------| | 触发频率 | 单次 | 高频重复 | | 可能场景 | 初始化操作 | 持续文件创建 | | 内存页消耗 | 1页 | 652页 | | 性能关注点 | 基础开销 | 潜在性能瓶颈 | $$技术建议:$$ 1. **高频分配诊断** - 使用 `slabtop -o` 观察 `dentry` 和 `kmalloc-*` 的 slab 使用量 - 检查 OverlayFS 层数配置:`mount -t overlay -o lowerdir=...` - 通过 `perf record -g -a` 捕获完整调用链 2. **优化方向** ```c // 典型 dentry 缓存参数调整 sysctl -w vm.vfs_cache_pressure=150 // 增加回收积极性 sysctl -w fs.dentry-state // 监控 dentry 缓存状态 ``` 3. **OverlayFS特性注意** - 写时复制(CoW)机制会导致频繁的 dentry 创建 - 检查 upperdir 文件系统的 I/O 性能 - 确认是否启用 `redirect_dir` 等优化特性 该现象可能表示: - 正常行为:大规模文件操作场景下的预期分配 - 异常情况:存在 dentry 泄漏或路径查找效率问题 建议结合 `dcache_stat` 统计和 `find /sys/kernel/slab/ -name "dentry"` 的 slab 信息进行深入分析。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值