On Wed, 14 Apr 2021 12:27:03 +0200 Ilya Leoshkevich <i...@linux.ibm.com> wrote:
> On Wed, 2021-04-14 at 11:19 +0200, Ilya Leoshkevich wrote: > > On Wed, 2021-04-14 at 10:38 +0200, Cornelia Huck wrote: > > > On Tue, 13 Apr 2021 18:52:57 +0200 > > > Ilya Leoshkevich <i...@linux.ibm.com> wrote: > > > > > > > Hitting an uretprobe in a s390x TCG guest causes a SIGSEGV. What > > > > happens is: > > > > > > > > * uretprobe maps a userspace page containing an invalid > > > > instruction. > > > > * uretprobe replaces the target function's return address with the > > > > address of that page. > > > > * When tb_gen_code() is called on that page, tb->size ends up being > > > > 0 > > > > (because the page starts with the invalid instruction), which > > > > causes > > > > virt_page2 to point to the previous page. > > > > * The previous page is not mapped, so this causes a spurious > > > > translation exception. > > > > > > > > The bug is that tb->size must never be 0: even if there is an > > > > illegal > > > > instruction, the instruction bytes that have been looked at must > > > > count > > > > towards tb->size. So adjust s390x's translate_one() to act this way > > > > for both illegal instructions and instructions that are known to > > > > generate exceptions. > > > > > > > > Also add an assertion to tb_gen_code() in order to detect such > > > > situations in future. > > > > > > > > Signed-off-by: Ilya Leoshkevich <i...@linux.ibm.com> > > > > --- > > > > > > > > v1: > > > > https://lists.nongnu.org/archive/html/qemu-devel/2021-04/msg02037.html > > > > v1 -> v2: Fix target/s390x instead of trying to tolerate tb->size > > > > == 0 > > > > in tb_gen_code(). > > > > > > > > accel/tcg/translate-all.c | 1 + > > > > target/s390x/translate.c | 16 +++++++++++----- > > > > 2 files changed, 12 insertions(+), 5 deletions(-) > > > > > > I assume this bug is not usually hit during normal usage, right? It's > > > probably not release critical, so I'll line it up for 6.1 instead. > > > > Yes, I saw it only with uprobes, and then it leads only to a process > > crash, not to a kernel crash. Thanks! > > Seems like the new assertion triggers on ARM: > > https://gitlab.com/cohuck/qemu/-/jobs/1178409450 Yep, I just wanted to make sure it was this patch before complaining :) > > What are the rules in s390x-next-staging, can we amend the patch, or > only commit a follow-up? -staging is before I merge properly, so no problem folding something in. > In either case, I think we'll need something > like this (untested): > > --- a/target/arm/translate.c > +++ b/target/arm/translate.c > @@ -9060,6 +9060,7 @@ static void > arm_tr_translate_insn(DisasContextBase *dcbase, CPUState *cpu) > unsigned int insn; > > if (arm_pre_translate_insn(dc)) { > + dc->base.pc_next += 4; > return; > } > > > I'm currently trying to debug this in more detail and test the fix. >