Re: Endless loop on execution attempt on non-executable page

[Ralf Baechle <ralf@linux-mips.org>]

On Thu, May 12, 2016 at 12:46:37PM +0200, Florian Weimer wrote:

> The GCC compile farm has a big-endian 64-bit MIPS box.  The kernel is:
> 
> Linux erpro8-fsf1 3.14.10-er8mod-00013-ge0fe977 #1 SMP PREEMPT Wed Jan
> 14 12:33:22 PST 2015 mips64 GNU/Linux
> 
> Which is a vendor kernel for the EdgeRouter Pro-8.
> 
> /proc/cpuinfo reports:
> 
> system type             : UBNT_E200 (CN6120p1.1-1000-NSP)
> machine                 : Unknown
> processor               : 0
> cpu model               : Cavium Octeon II V0.1
> 
> While testing W^X (execmod, DEP, NX) stack enforcement, I noticed that once
> I try to execute code off a non-executable page, I do not get a signal, but
> the code appears to enter an infinite loop.  The generated function starts
> with a jump instruction to return to the caller, but instead, the program
> counter does not seem to change at all.
> 
> “si” in GDB also hangs (but can be interrupted with ^C).
> 
> My test code is here:
> 
>   https://pagure.io/execmod-tests
> 
> Is this a kernel bug or an issue with the silicon?

I see the test case uses mprotect to add PROT_EXEC after writing the code
to memory.  I don't think mprotect however gives any guarantee that this
will make the I-cache coherent with the D-cache, that is that the CPU will
actually fetch and execute the instruction that were just written to memory.
For that you have to do something architecture specific such as dancing
around a fire waving a dead chicken.  Or on MIPS call cacheflush(), see
the man page for details.

For portability sake to some broken processors you should also ensure
that a 32 byte cache line is entirely filled with valid instructions by
padding the two test instructions with another six no-op (opcode 0).
The test case as it is guarantees this implicitly by using a freshly
allocated page but I thought I should mention it.

  Ralf