Hello Hugo,
I'm afraid some misconceptions about the devmem2 tool lead this.
On Wed, Jun 30, 2021 at 19:38:44 CEST, Hugo V.C. wrote:
> root@dev:/home/hugo/seL4/utilidades_sel4webserver# strace devmem2
> 7ffc8402e000
> execve("/usr/bin/devmem2", ["devmem2", "7ffc8402e000"], 0x7ffc8a099a68 /*
> 21 vars */) = 0
> (...)
This command line instructs devmem2 to read physical (logical) memory
address 7 because it misses the 0x prefix. See below for the result.
> write(1, "/dev/mem opened.\n", 17/dev/mem opened.
> ) = 17
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7f161b205000
> write(1, "Memory mapped at address 0x7f161"..., 41Memory mapped at address
> 0x7f161b205000.
> ) = 41
> write(1, "Value at address 0x7 (0x7f161b20"..., 48Value at address 0x7
> (0x7f161b205007): 0x60E0F0
> ) = 48
The tool read address 0x7.
> # ls /proc/283/maps
[...]
> ffffe6c58000-ffffe6c79000 rw-p 00000000 00:00 0
> [stack]
>
> # devmem 0xffffe6c58000 8
In this case the 0x prefix there but I expect the requested memory
address is outside of the available memory (and also does not
correspong to any MMIO region). So, make sure to call devmem2 with the
"physical address of a page frame" and not with some virtual-memory
mapping from proc-maps.
The following line should be expected if the guest OS accesses
guest-physical addresses without backing memory in the VMM.
> [email protected]:266 Failed to find any untyped capable of
> creating an object at address 0xffffe6c58000
> [email protected]:68 Failed to map page at address 0xffffe6c58000 with
> cap 396187, error: 1
> [email protected]:153 Error mapping pages, bailing: 1
> map_vm_memory_reservation@guest_memory.c:477 Failed to map address
> 0xe6c58000 into guest vm vspace
> vm_map_reservation@guest_memory.c:510 Failed to map vm reservation: Error
> when mapping into VM's vspace
[...]
> My three concerns here are:
>
> 1) Why this guest mmap() is crashing the VM? Memory address is valid
> (just guest user space process stack).
This is because you requested the guest OS to access invalid physical
memory (with root privileges).
Regards
--
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 -- [email protected]
To unsubscribe send an email to [email protected]
