Ok, from "https://busybox.net/downloads/busybox-1.31.0.tar.bz2" which is
the version packed in the "demo" seL4 VM Linux guest, looks like devmem is
not working like you say (devmem2). Look at this:
/* devmem ADDRESS [WIDTH [VALUE]] */
// TODO: options?
// -r: read and output only the value in hex, with 0x prefix
// -w: write only, no reads before or after, and no output
// or make this behavior default?
// Let's try this and see how users react.
/* ADDRESS */
if (!argv[1])
bb_show_usage();
errno = 0;
target = bb_strtoull(argv[1], NULL, 0); /* allows hex, oct etc */
that's the first thing that was confusing me (different behavior from
devmem2).
On the other side, still need to understand why an mmap() is crashing the
guest/VM from user space (root is user space). This is insane to me, so I
suspect may I have enabled/disabled something in the kernel config to allow
this. All this is independent to the fact that, as you pointed out, devmem
reads physical addresses and /proc/pid/maps shows virtual addresses thus I
need to translate them in some way. My fault :(
Thank you for your help!
El jue, 1 jul 2021 a las 16:59, Hugo V.C. (
Hi Christian,
ok, I updated my kernel to the latest available version (just in case it was something already patched at Linux kernel). Then I managed to have a strace in my seL4 Linux guest. Here you have the output:
# cat /proc/284/maps 00400000-00532000 r-xp 00000000 00:02 6023 /bin/lighttpd 00541000-00543000 r--p 00131000 00:02 6023 /bin/lighttpd 00543000-00546000 rw-p 00133000 00:02 6023 /bin/lighttpd 00546000-0054d000 rw-p 00000000 00:00 0 3ab85000-3aba7000 rw-p 00000000 00:00 0 [heap] ffff9f205000-ffff9f206000 r--p 00000000 00:00 0 [vvar] ffff9f206000-ffff9f207000 r-xp 00000000 00:00 0 [vdso] ffffc7931000-ffffc7952000 rw-p 00000000 00:00 0 [stack] # ./strace devmem 0xffffc7931000 execve("/sbin/devmem", ["devmem", "0xffffc7931000"], [/* 11 vars */]) = 0 readlinkat(AT_FDCWD, "/proc/self/exe", "/bin/busybox", 4096) = 12 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa6bd5000 openat(AT_FDCWD, "/lib//libc.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=510632, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa6bd4000 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\300Q\1\0\0\0\0\0"..., 4096) = 4096 mmap(NULL, 679936, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa6b1c000 mmap(0xffffa6b1c000, 502012, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xffffa6b1c000 mmap(0xffffa6ba7000, 5244, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x7b000) = 0xffffa6ba7000 mmap(0xffffa6ba9000, 99848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffffa6ba9000 close(3) = 0 munmap(0xffffa6bd4000, 4096) = 0 newfstatat(AT_FDCWD, "/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=33864, ...}, 0) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa6bd4000 mprotect(0x4c2000, 4096, PROT_READ) = 0 mprotect(0xffffa6ba7000, 4096, PROT_READ) = 0 mprotect(0xffffa6bd8000, 4096, PROT_READ) = 0 set_tid_address(0xffffa6bd40d0) = 331 set_robust_list(0xffffa6bd40e0, 24) = 0 rt_sigaction(SIGRTMIN, {0xffffa6b78ae8, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xffffa6b78ba8, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 getuid() = 0 openat(AT_FDCWD, "/dev/mem", O_RDONLY|O_SYNC) = 3 mmap(NULL, 4096, PROT_READ, MAP_SHARED, 3, 0xffffc7931000) = 0xffffa6bd3000 _utspace_split_alloc@split.c:266 Failed to find any untyped capable of creating an object at address 0xffffc7931000 map_page@mapping.c:68 Failed to map page at address 0xffffc7931000 with cap 396187, error: 1 sel4utils_map_page_pd@vspace.c:153 Error mapping pages, bailing: 1 map_vm_memory_reservation@guest_memory.c:477 Failed to map address 0xc7931000 into guest vm vspace vm_map_reservation@guest_memory.c:510 Failed to map vm reservation: Error when mapping into VM's vspace -------- Pagefault from [Linux]: read fault @ PC: 0x414c70 IPA: 0xffffc7931000, FSR: 0x93820004 Context: x0: 0xffffa6bd3000 x1: 0x0 x2: 0x0 x3: 0x1 x4: 0x3 x5: 0xffffc7931000 x6: 0xf x7: 0x20 x8: 0xde x9: 0xffffeb09bf54 x10: 0xffffa6bd5050 x11: 0x1 x12: 0x436 pc: 0x414c70 x14: 0xffffffff sp: 0xffffeb09b820 spsr: 0x60000000 x13: 0x1 x15: 0x3 x16: 0xffffa6b356c8 x17: 0x4c3870 x18: 0x0 x19: 0x20 x20: 0x0 x21: 0x4c3000 x22: 0xffffeb09ba40 x23: 0xffffc7931000 x24: 0x0 x25: 0x0 x26: 0x0 x27: 0x0 x28: 0x0 x29: 0xffffeb09b910 x30: 0x414bac m-------- main_continued@main.c:1134 Failed to run VM Halting...
Clearly here I can see devmem is not taking "0x" as argument but the full address passed in the argument. And what I see is the last system call is:
mmap(NULL, 4096, PROT_READ, MAP_SHARED, 3, 0xffffc7931000) = 0xffffa6bd3000
before seL4 VM crashes.
El jue, 1 jul 2021 a las 14:18, Christian Helmuth (< christian.helmuth@genode-labs.com>) escribió:
Hi Hugo,
let me clarify that the strace I provided is from my host machine (a common Linux distro) which provides "devmem2" that do not requires "0x" before
On Thu, Jul 01, 2021 at 10:28:10 CEST, Hugo V.C. wrote: the
address.
I'm very aware of the fact that your strace was recorded with an ordinary Linux distro, but still devmem2 needs the 0x prefix to translate your command-line argument (speak string) into an integer value.
In fact, if you try with "0x" you get this argument error:
root@dev:/home/hugo# devmem2 0x7ffc8402e000 /dev/mem opened. Error at line 75, file devmem2.c (22) [Invalid argument]
It seems you're lucky because your Linux kernel does not access arbitrary physical addresses but warns you about 0x7ffc8402e000 beeing an invalid argument for mmap("/dev/mem") [1].
Instead, if you pass the argument without "0x" tehn looks like it works:
root@dev:/home/hugo# devmem2 7ffc8402e000 /dev/mem opened. Memory mapped at address 0x7fcea478e000. Value at address 0x7 (0x7fcea478e007): 0x60E0F0
Sorry no, it does not work as you expect it to work. Please consider devmem2 translates your address argument like follows [2].
#include
#include int main() { printf("i0=%lx\n", strtoul("7fff", 0, 0)); }
If you try this, you will see that strtoul stops parsing the number on the occurrence of the first f character because this is no decimal digit.
I really don't know why the devmem2 says "Value at address 0x7" even if later it clarifies that the address is "0x7fcea478e007". In fact, in all the strace you can see the address handled is "0x7fcea478e007" and not "0x7":
Please see above because your argument 7ffc8402e000 is parsed to 0x7. And please, consider the difference between virtual-memory addresses and physical-memory addresses.
as you can see mmap() here is taking the address I passed by argument "mmap(NULL, 102488, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbca43a7000". An later all the mmap() calls are using the address as passed by argument (0x7fbca43a7000). Finally you can see the write() call taking the right address too: write(1, "Value at address 0x7 (0x7fbca43e"..., 48Value at address 0x7 (0x7fbca43ed007): 0x60E0F0
Would you agree that the following numbers are quite different 7ffc8402e000, 0x7, and 0x7fbca43ed007? Only 0x7 is a physical address in my opinion.
For information on how to retrieve page-frame numbers from virtual-memory maps please consider [3] which I discovered on Stack OVerflow [4].
[1] https://github.com/hackndev/tools/blob/7ed212230f8fbb1da3424a15ee88de3279bf9... [2] https://github.com/hackndev/tools/blob/7ed212230f8fbb1da3424a15ee88de3279bf9... [3] https://github.com/dwks/pagemap [4] https://unix.stackexchange.com/q/624746/334627
Greets -- Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems