On 8/22/19 6:15 AM, Peter Maydell wrote: > The upshot of all this is that for linux-user mode we should never > do any of the bx_excret magic, so the code change is simple. > > This ought to be a weird corner case that only affects broken guest > code (because Linux user processes should never be attempting to do > exception returns or NS function returns), except that the code that > assigns addresses in RAM for the process and stack in our linux-user > code does not attempt to avoid this magic address range, so > legitimate code attempting to return to a trampoline routine on the > stack can fall into this case. This change fixes those programs, > but we should also look at restricting the range of memory we > use for M-profile linux-user guests to the area that would be > real RAM in hardware. > > Cc: qemu-sta...@nongnu.org > Reported-by: Christophe Lyon <christophe.l...@linaro.org> > Fixes: https://bugs.launchpad.net/qemu/+bug/1840922 > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org> > I have no idea how we could achieve the "restrict addresses > shown to guest for linux-user" mentioned in the last para: > any suggestions? I guess we'd want a new cpu hook, and change MAX_RESERVED_VA from a macro into a function call. Move the cpu_create() in linux-user/main.c up a few lines before we default reserved_va for 64-bit hosts. Move the check of the command-line setting of reserved_va vs MAX_RESERVED_VA out from handle_arg_reserved_va to just after the aforementioned default. Seems plausible, anyway. r~
