[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with signals and illegal instructions in user mode

From: Gabe Black
Subject: Re: Problems with signals and illegal instructions in user mode
Date: Fri, 10 Apr 2020 04:19:18 -0700

I've expanded my set of tests to know include a call mechanism that's based on accesses to a special region of memory, and I'm having problems with that too. I'm trying to use mprotect to block the pages that map to the magic region so that when the utility attempts to access them, it will get a SIGSEGV and I can look at what it tried to do.

Running that test program natively on my x86 workstation works, but I have problems when I run it for aarch64 in qemu. If I mprotect it with the protection set to 0, it acts like it's not there at all (the si_code is for an unmapped area, not access permissions), and if I mprotect it to have any permissions at all, the magic read is allowed to happen without a SIGSEGV even if there are no read permissions.

Is this a fuzzy edge of the system calls QEMU can emulate? I'm hoping to be able to use QEMU to run these test programs quickly with low overhead as part of our test suite, but from my experience with a similar user mode in our own simulator, I understand how getting all these details right can be very hard and not always worth the trouble.


On Fri, Apr 10, 2020 at 12:21 AM Gabe Black <address@hidden> wrote:
After working on this a little longer, I think there were two problems with the thumb binary, that the return wasn't interworking, and the function wasn't marked as thumb properly, so the interworking branch that went into it ran it in ARM mode. After fixing those two problems that binary works.

I'm still having problems with the SPARC and ARM binaries though, so I could still use some help!


On Thu, Apr 9, 2020 at 10:14 PM Gabe Black <address@hidden> wrote:
Hi! I work on an open source simulator called gem5 (www.gem5.org), and I'm trying to use QEMU to validate a little binary we have which runs inside the simulator and lets software/users within the simulation request services from the simulator itself.

The utility program, called "m5" for historical reasons, can make those requests in several ways, but the one I'm trying to test is by using magical instructions which are normally undefined, but which the simulator hooks into. I wrote a test program which takes the actual call sight and wraps it in some testing code which attempts to handle the SIGILL, capture information about where it happened, and then use a siglongjmp to go back to somewhere sane to analyze that info and make sure the right instruction triggered the SIGILL, that it was requesting the right service, etc. This test code is intended to run on real or "real" hardware which won't have an implementation for the magic instructions, and since QEMU should fit and should be easy to run and should be trustworthy as far as implementing the ISA correctly, etc., I wanted to verify within that.

Unfortunately, depending on what target architecture I use, how QEMU actually responds is a little all over the map.

qemu-aarch64 - Works as expected. There is a SIGILL, it happens in the right place, and is caught correctly.

qemu-arm - No illegal instruction. The instruction is:
mcr     1, 1, r0, cr3, cr0, {0}
which I *think* should count as illegal because it uses coprocessor 1, and to my knowledge there isn't a coprocessor 1 typically. Does QEMU emulate one there, and can I tell it not to?

qemu-arm (thumb binary) - A SIGILL happens, but the si_addr field of the siginfo_t is not actually at the instruction I expect. This could be because the assembly code it's written with doesn't handle interworking branches correctly? I think despite flags telling the compiler to use thumb it used ARM anyway, except for the little call sight which is in thumb assembly.

qemu-sparc - A SIGILL happens, but my earlier call to sigaction seems to have been ignored, and the default handler fires killing the binary.

Other than the little binary stub and a macro which extracts some info from si_addr after the misbehaving part, these versions all use the same code. I've had some trouble trying this on actual hardware and so can't rule out a bug in the implementation, but I suspect something funny is happening in QEMU.

Any help is appreciated!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]