Endless loop on execution attempt on non-executable page

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?

Quoted 20 lines · Florian Weimer

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.

Quoted 7 lines

“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.

Quoted 30 lines · Ralf Baechle

Quoted 20 lines · Florian Weimer

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.

Quoted 7 lines

“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?

Quoted 7 lines

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.

There is a fork between the write and the execute. It is somewhat unlikely that that's not a barrier, but it did happen on POWER.

However, I can successfully execute code without the barrier, so this whole thing goes in the wrong direction. :)

I have added it, just to be on the safe side.

Quoted 3 lines

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).

Added as well.

Quoted 2 lines

The test case as it is guarantees this implicitly by using a freshly allocated page but I thought I should mention it.

There are some tests that don't (the stack variable might be clobbered, for example).

Anyway, neither change fixed things for me. Given the peculiar “si” behavior in GDB, that's not entirely unexpected ...

Quoted 56 lines · Florian Weimer

Quoted 30 lines · Ralf Baechle

Quoted 20 lines · Florian Weimer

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.

Quoted 7 lines

“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?

Quoted 7 lines

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.

There is a fork between the write and the execute. It is somewhat unlikely that that's not a barrier, but it did happen on POWER.

However, I can successfully execute code without the barrier, so this whole thing goes in the wrong direction. :)

I have added it, just to be on the safe side.

Quoted 3 lines

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).

Added as well.

Quoted 2 lines

The test case as it is guarantees this implicitly by using a freshly allocated page but I thought I should mention it.

Quoted 5 lines

There are some tests that don't (the stack variable might be clobbered, for example).

Anyway, neither change fixed things for me. Given the peculiar “si” behavior in GDB, that's not entirely unexpected ...

Thanks for fixing and testing this obvious things. Now let's look one or two levels deeper ...

This is something that would be easy to diagnose on the OCTEON simulator...

Before spending time doing that, has anyone tried this on current kernels rather than the 3.14 indicated above?