From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 May 2016 16:23:12 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:46018 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S27028555AbcELOXHljrUu (ORCPT ); Thu, 12 May 2016 16:23:07 +0200 Received: from scotty.linux-mips.net (localhost.localdomain [127.0.0.1]) by scotty.linux-mips.net (8.15.2/8.14.8) with ESMTP id u4CEN7c9014715; Thu, 12 May 2016 16:23:07 +0200 Received: (from ralf@localhost) by scotty.linux-mips.net (8.15.2/8.15.2/Submit) id u4CEN61R014714; Thu, 12 May 2016 16:23:06 +0200 Date: Thu, 12 May 2016 16:23:06 +0200 From: Ralf Baechle To: Florian Weimer Cc: linux-mips@linux-mips.org Subject: Re: Endless loop on execution attempt on non-executable page Message-ID: <20160512142306.GT16402@linux-mips.org> References: <57345F0D.9070503@redhat.com> <20160512125342.GS16402@linux-mips.org> <9af052f6-b50c-7ba5-ebbb-0bdff0c58dd9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9af052f6-b50c-7ba5-ebbb-0bdff0c58dd9@redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 53410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Thu, May 12, 2016 at 03:07:51PM +0200, Florian Weimer wrote: > On 05/12/2016 02:53 PM, Ralf Baechle wrote: > > 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. > > 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. > > > 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. > > > 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 ... Thanks for fixing and testing this obvious things. Now let's look one or two levels deeper ... Ralf