如何生成网站的二维码,wordpress get_attached_media,哈尔滨建站系统,哪家好做网站1.MTE概念 MTE#xff08;内存标记扩展#xff09;是ARM v8.5-A新增的一项缓解内存安全的机制。在Android Linux现有的安全机制中#xff0c;类似的机制有ASAN、HWSAN。但两者因为性能开销代价高昂#xff0c;不适用于广泛部署#xff08;仅调试使用#xff09;。MTE当前…1.MTE概念 MTE内存标记扩展是ARM v8.5-A新增的一项缓解内存安全的机制。在Android Linux现有的安全机制中类似的机制有ASAN、HWSAN。但两者因为性能开销代价高昂不适用于广泛部署仅调试使用。MTE当前带来了一种高性能、可扩展的硬件解决方案可降低以不安全语言编写的代码中可能存在的内存安全违规风险。 注MTE不仅可用在研发自测、内存问题调试也可以用于Fuzz。 2.MTE支持条件 ARM解释 v8.5及以上 Qcom平台解释ARM v9MSM8450以上 Android解释Android对MTE的支持将在2021年/2022年初发布带有MTE的芯片时完成。截至于2023年底最新的旗舰设备Pixel、OPPO开发者选项中已具备MTE功能。 3.MTE的开关 内核层CONFIG_ARM64_MTEy时开启此Kconfig由平台根据环境自行控制无需工程师手动开关。依赖情况如下 1687config ARM64_MTE1688 bool Memory Tagging Extension support1689 default y1690 depends on ARM64_AS_HAS_MTE  ARM64_TAGGED_ADDR_ABI1691 depends on AS_HAS_ARMV8_51692 # Required for tag checking in the uaccess routines1693 depends on ARM64_PAN1694 depends on AS_HAS_LSE_ATOMICS1695 select ARCH_USES_HIGH_VMA_FLAGS1696 help Google Play中也提供了APPSanitizer Test APP[外网需要科学上网]可用于测试MTE例如 4.MTE检测目标 MTE认为内存安全违规主要分2种空间安全、时间安全。 空间安全 对象在真实边界之外被访问例如溢出、越界等。可被利用来改变函数指针、保存寄存器等目标地址。 时间安全 在对象引用的内存释放、过期后使用。例如UAF等攻击者可以放置一个新的恶意对象来代替预期目标。 下图是两类内存违规的代码表视图 5.MTE的检测原理 总体思路 MTE实现了对内存的锁和密钥的验证关系通过在指针上增加密钥在内存中加入锁。在指针访问内存时密钥与锁进行验证。如果匹配则允许内存访问否则访问会被记录、拦截。通过这种方式来检测、捕捉内存安全问题。整体逻辑如下图 技术实现 ARM64 架构使用64位指针来寻址内存。其中通常有48~52位被硬件实际使用如果由开启large-address-space则是52位。所以理论上有12-16位是预留的。ARM架构一直有“TOP BYTE IGNORE”高字节忽略的功能允许软件在虚拟地址的最高字节中存储任意数据但直到MTE前这些位依然是没有使用。 MTE允许在虚拟地址的59-56位即最上层字节的低4位存储一个key作为密钥。也会将这个密钥与一个或多个16字节的内存范围关联单独存储作为“锁”。当一个指针简介访问此内存区域时存储在指针中的密钥会与指针引用内存的关联密钥进行校验。 密钥来源 密钥可以由应用程序管理keymaster产生也可以由CPU随机生成。 6.MTE的实际效果 以2020年修复libjpeg-trubo库漏洞CVE-2020-13790为例。此漏洞是JPEG图像编解码器在加载格式错误的img文件时导致的堆缓冲区溢出。以下是MTE开启时漏洞触发的情景 可以看到在漏洞复现时MTE轻松的捕获到进程会因为分段错误导致中止。故障的存储会通过logcat打印。从图中可以看到 奔溃的原因MTE崩溃的类型Buffer Overflow堆的大小以及溢出的大小:104 bytes right of a 16151-byte问题地址pc指针00000056d2240ddc进程idpid187tid187CPU寄存器信息堆栈的回溯信息 通过addr2line解析pc指针可以找到问题出现的地址 7.MTE的处理措施 当PROT_MTE相关特性页表允许MTE分配标签已开启并且检测出异常时有三种不同的选项 Ignore模式PR_MTE_TCF_NONE这是默认模式。CPU和内核将忽略MTE检测错误如果未设置也默认此选项。同步模式PR_MTE_TCF_SYNC内核引发SIGSEGV同步并且引发SEGV_MTESERR和si_codefauly-address。并且内存访问会被拦截如果SIGSEGV被阻塞或忽略则包含的进程将通过coredump中止。异步模式PR_MTE_TCF_ASYNC在一个或多个线程检测错误后内核引发SIGSEGV并设置SEGV_MTAERR和si_code0 8.MTE的性能开销 以上是官方给出的性能开销结论 同步模式能够识别精确指令和地址但对性能开销较大 异步模式成本更低再测试工作负载和基准测试中性能开销估计为1%~2%但异步检测提供是失败信息可能不太准确但它可以提供一些缓解错误信息并用于分析以便缩小排查范围。 9.上手实效 据2023年8月Google Project Zero发布的一篇博文《Fitst handset with MTE on market》呈现博主在Pixel 8上开启了MTE正常日常使用中未发现任何异常也没有感受到性能受到影响。 作为世界顶级安全团队的Zero自然也编写了一个具备OOB的Poc进行测试源码如下 extern C JNIEXPORT jstring JNICALLJava_com_example_mtetestapplication_MainActivity_stringFromJNI(JNIEnv* env,jobject /* this */) {char* ptr strdup(test string);free(ptr);// Use-after-free when ptr is accessed below.return env-NewStringUTF(ptr);} 测试的结果如下视频请参考原始地址以下仅为logcat打印可以明显看到崩溃原因是testapplication程序发生了UAF。 EBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***DEBUG : Build fingerprint: google/shiba/shiba:14/UD1A.230803.041/10808477:user/release-keysDEBUG : Revision: MP1.0DEBUG : ABI: arm64DEBUG : Timestamp: 2023-10-24 16:56:32.0925328860200DEBUG : Process uptime: 2sDEBUG : Cmdline: com.example.mtetestapplicationDEBUG : pid: 24147, tid: 24147, name: testapplication com.example.mtetestapplication DEBUG : uid: 10292DEBUG : tagged_addr_ctrl: 000000000007fff3 (PR_TAGGED_ADDR_ENABLE, PR_MTE_TCF_SYNC, mask 0xfffe)DEBUG : pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)DEBUG : signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0b000072afa9f790DEBUG : x0 0000000000000001 x1 0000007fe384c2e0 x2 0000000000000075 x3 00000072aae969acDEBUG : x4 0000007fe384c308 x5 0000000000000004 x6 7274732074736574 x7 00676e6972747320DEBUG : x8 0000000000000020 x9 00000072ab1867e0 x10 000000000000050c x11 00000072aaed0af4DEBUG : x12 00000072aaed0ca8 x13 31106e3dee7fb177 x14 ffffffffffffffff x15 00000000ebad6a89DEBUG : x16 0000000000000001 x17 000000722ff047b8 x18 00000075740fe000 x19 0000007fe384c2d0DEBUG : x20 0000007fe384c308 x21 00000072aae969ac x22 0000007fe384c2e0 x23 070000741fa897b0DEBUG : x24 0b000072afa9f790 x25 00000072aaed0c18 x26 0000000000000001 x27 000000754a5fae40DEBUG : x28 0000007573c00000 x29 0000007fe384c260DEBUG : lr 00000072ab35e7ac sp 0000007fe384be30 pc 00000072ab1867ec pst 0000000080001000DEBUG : 98 total framesDEBUG : backtrace:DEBUG : #00 pc 00000000003867ec /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess, bool, char const*, art::(anonymous namespace)::JniValueType*) (.__uniq.99033978352804627313491551960229047428)1636) (BuildId: a5fcf27f4a71b07dff05c648ad58e3cd)DEBUG : #01 pc 000000000055e7a8 /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::CheckJNI::NewStringUTF(_JNIEnv*, char const*) (.__uniq.99033978352804627313491551960229047428.llvm.6178811259984417487)160) (BuildId: a5fcf27f4a71b07dff05c648ad58e3cd)DEBUG : #02 pc 00000000000017dc /data/app/~~lgGoAt3gB6oojf3IWXi-KQ/com.example.mtetestapplication-k4Yl4oMx9PEbfuvTEkjqFg/base.apk!libmtetestapplication.so (offset 0x1000) (_JNIEnv::NewStringUTF(char const*)36) (BuildId: f60a9970a8a46ff7949a5c8e41d0ece51e47d82c)...DEBUG : Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.DEBUG : Cause: [MTE]: Use After Free, 0 bytes into a 12-byte allocation at 0x72afa9f790DEBUG : deallocated by thread 24147:DEBUG : #00 pc 000000000005e800 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocatorscudo::AndroidConfig, (scudo_malloc_postinit)::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)496) (BuildId: a017f07431ff6692304a0cae225962fb)DEBUG : #01 pc 0000000000057ba4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocatorscudo::AndroidConfig, (scudo_malloc_postinit)::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)212) (BuildId: a017f07431ff6692304a0cae225962fb)DEBUG : #02 pc 000000000000179c /data/app/~~lgGoAt3gB6oojf3IWXi-KQ/com.example.mtetestapplication-k4Yl4oMx9PEbfuvTEkjqFg/base.apk!libmtetestapplication.so (offset 0x1000) (Java_com_example_mtetestapplication_MainActivity_stringFromJNI40) (BuildId: f60a9970a8a46ff7949a5c8e41d0ece51e47d82c) 10.结论 从目前看来启用MTE在性能、续航上的削弱并不明显但在安全上的提升十分显著。是这些年来继CFI后最重要的商用安全特性小编自己评的如果不准确请不要喷我。许多0-click的攻击面都会涉及大量C/C的安全问题。当前MTE也不是内存安全的最终答案开启后能够提高安全性但不意味着安全万无一失 11.参考资料 参考资料链接Kernel 5.15.0-rcl MTEhttps://www.kernel.org/doc/html/latest/arm64/memory-tagging-extension.htmlTools and SoftwareTools and SoftwareARM Developer MTELWNArm64的内存标记扩展功能-CSDN博客CSDN LWNARM64的内存标记扩展功能https://developer.arm.com/architectures/cpu-architecture/a-profile?_ga2.256687755.1292256680.1566735535-2019613222.1563850500#mteARM MTE白皮书https://www.wwwbuild.net/androidperf/74222.html