QEMU 托管启用 MTE 的内核不会引发故障 [英] QEMU hosting MTE enabled kernel does not raise fault

查看:29
本文介绍了QEMU 托管启用 MTE 的内核不会引发故障的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试在 QEMU 环境(运行支持 MTE 的内核)上编译和测试 ARMv8.5 MTE 扩展.

我尝试在承载启用 MTE 的内核的 QEMU 上引发错误.我有一个简单的 C 代码,我运行它应该会因为 MTE 而引发错误,但它运行得很好(附加日志和信息).我在 x86 机器上将代码交叉编译为 arm64,并带有相关的 clang MTE 相关标志.

5.4.0-1040-gcp #43-Ubuntu SMP Fri Mar 19 17:49:48 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux 上编译

Linux lab 5.11.13 #1 SMP PREEMPT Sun Apr 11 11:30:52 UTC 2021 aarch64 GNU/Linux 上运行可执行文件,使用 CONFIG_ARM64_MTE=y>

代码:

#include #include #include #include int main(){printf(嗨 %ld\n", (long)getpid());int *array = (int*) malloc (sizeof(int) * 1);数组[32] = 1;printf("这里是值:%d", array[32]);返回0;}

clang-11 标志:

clang-11 -target aarch64-linux-gnu -march=armv8+memtag -fsanitize=memtag main.c -static

QEMU 版本:

lab@qemu-mte:~$ qemu-system-aarch64 --versionQEMU 模拟器版本 5.2.92

QEMU 标志:

sudo/opt/qemu/build/qemu-system-aarch64 -machine virt,mte=on -cpu max -kernel Image -hda stretch.img -m 2G -display none -serial stdio -append "root=/dev/vda"

可执行的strace输出:

root@lab:/# strace ./testexecve("./test", ["./test"], [/* 11 vars */]) = 0brk(NULL) = 0x3ada7000brk(0x3ada7f80) = 0x3ada7f80uname({sysname="Linux", nodename="lab", ...}) = 0readlinkat(AT_FDCWD, "/proc/self/exe", "/test", 4096) = 5brk(0x3adc8f80) = 0x3adc8f80brk(0x3adc9000) = 0x3adc9000mprotect(0x489000, 4096, PROT_READ) = 0getpid() = 235fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(204, 64), ...}) = 0ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0写(1,嗨235\n",7嗨235) = 7write(1, "here is the value: 1", 20here is the value: 1) = 20exit_group(0) = ?+++ 以 0 +++ 退出

我错过了什么吗?如果需要任何其他信息,请告诉我.谢谢.

解决方案

该 strace 日志中的任何内容似乎都没有为进程启用 MTE,这似乎很可疑.尝试构建并运行 内核中给出的示例 MTE 程序MTE 的文档.这完全是手动"执行 MTE,即没有编译器的帮助.如果它有效,那么您可以开始查看事物的叮当声;如果它不起作用,则需要检查 QEMU 和内核.

I'm trying to compile and test ARMv8.5 MTE extensions on QEMU environment (running MTE-enabled kernel).

I try to raise a fault on QEMU that hosts a kernel with MTE enabled. I have a simple C code I run that should raise a fault because of MTE, but it runs just fine (attaching logs and info). I cross compile the code to arm64 on a x86 machine, with the relevant clang MTE-related flags.

compiling on 5.4.0-1040-gcp #43-Ubuntu SMP Fri Mar 19 17:49:48 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

running the executable on Linux lab 5.11.13 #1 SMP PREEMPT Sun Apr 11 11:30:52 UTC 2021 aarch64 GNU/Linux with CONFIG_ARM64_MTE=y

The code:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
 
int main()
{
        printf("Hi %ld\n", (long)getpid());
        int *array = (int*) malloc (sizeof(int) * 1);
        array[32] = 1;
        printf("here is the value: %d", array[32]);
        return 0;
}

clang-11 flags:

clang-11 -target aarch64-linux-gnu -march=armv8+memtag -fsanitize=memtag main.c -static

QEMU version:

lab@qemu-mte:~$ qemu-system-aarch64 --version
QEMU emulator version 5.2.92

QEMU flags:

sudo /opt/qemu/build/qemu-system-aarch64 -machine virt,mte=on -cpu max  -kernel Image -hda stretch.img -m 2G -display none -serial stdio -append "root=/dev/vda"

executable strace output:

root@lab:/# strace ./test
execve("./test", ["./test"], [/* 11 vars */]) = 0
brk(NULL)                               = 0x3ada7000
brk(0x3ada7f80)                         = 0x3ada7f80
uname({sysname="Linux", nodename="lab", ...}) = 0
readlinkat(AT_FDCWD, "/proc/self/exe", "/test", 4096) = 5
brk(0x3adc8f80)                         = 0x3adc8f80
brk(0x3adc9000)                         = 0x3adc9000
mprotect(0x489000, 4096, PROT_READ)     = 0
getpid()                                = 235
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(204, 64), ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "Hi 235\n", 7Hi 235
)                 = 7
write(1, "here is the value: 1", 20here is the value: 1)    = 20
exit_group(0)                           = ?
+++ exited with 0 +++

Am I missing something? If any additional information is needed, please let me know. Thanks.

解决方案

Nothing in that strace log seems to be doing anything to enable MTE for the process, which seems suspicious. Try building and running the example MTE program given in the kernel documentation for MTE. That does MTE entirely "manually", i.e. without help from the compiler. If it works then you can start looking at the clang side of things; if it doesn't work then you need to check the QEMU and kernel.

这篇关于QEMU 托管启用 MTE 的内核不会引发故障的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆