arm64: issue with invalid mode handling
mark.rutland at arm.com
Wed Jan 18 08:10:31 PST 2017
On Wed, Jan 18, 2017 at 10:56:51AM -0500, Mark Salter wrote:
> Recently, I've run across some bug reports with:
> Internal error: Attempting to execute userspace memory: 8600000f
> But the real problem comes before just before this. Something like:
> Bad mode in Error handler detected on CPU0, code 0xbe000000 -- SError
> Bad mode in FIQ handler detected on CPU0, code 0x56000000 -- SVC (AArch64)
> In handling the bad mode exceptions happening in userspace, the kernel
> ends up trying to send SIGILL to the task but there is no path back to
> userspace. In entry.S, there is:
> .macro inv_entry, el, reason, regsize = 64
> kernel_entry \el, \regsize
> mov x0, sp
> mov x1, #\reason
> mrs x2, esr_el1
> b bad_mode
> which SError and others use. When bad_mode() returns, the LR actually
> contains the userspace address and the above internal error results.
Thanks for the report, it's much appreciated.
> So, what is the intent here? Should the kernel actually try to kill the
> task and keep going for these sorts of things or should it panic?
This was an unintended consequence of commit 9955ac47f4ba1c95 ("arm64:
don't kill the kernel on a bad esr from el0"), which was intended to
cater for certain synchronous exceptions.
We should treat SError as fatal; I'll spin a patch to correct that and
to avoid the erroneous return.
More information about the linux-arm-kernel