linux-kernel - Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6d7b45eb-8085-47fa-fc31-5fb26b7dd009@linux-m68k.org>
Date:	Thu, 21 Jul 2016 16:58:12 +1000
From:	Greg Ungerer <gerg@...ux-m68k.org>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU

Hi Nicolas,

On 21/07/16 05:22, Nicolas Pitre wrote:
> This series provides the necessary changes to allow "flat" executable
> binaries meant for no-MMU systems to actually run on systems with a MMU.
> Also thrown in are various cleanups to binfmt_flat.c.

I got to the bottom of why I couldn't run m68k flat binaries on
an MMU enabled m68k system. I had to fix the regs setup, with the
patch below. With this I can now run flat binaries on my ColdFire
MMU enabled system.

This change is completely independent of your patch series so I'll
push this separately via the linux-m68k list and my m68knommu git
tree.

Regards
Greg

Subject: [PATCH] m68k: fix bFLT executable running on MMU enabled systems

Even after recent changes to support running flat format executables on
MMU enabled systems (by nicolas.pitre@...aro.org) they still failed to
run on m68k/ColdFire MMU enabled systems. On trying to run a flat format
binary the application would immediately crash with a SIGSEGV.

Code to setup the D5 register with the base of the application data
region was only in the non-MMU code path, so it was not being set for
the MMU enabled case. Flat binaries on m68k/ColdFire use this to support
GOT/PIC flat built application code.

Fix this so that D5 is always setup when loading/running a bFLT executable
on m68k systems.

Signed-off-by: Greg Ungerer <gerg@...ux-m68k.org>
---
 arch/m68k/include/asm/flat.h      | 6 ++++++
 arch/m68k/include/asm/processor.h | 2 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/include/asm/flat.h b/arch/m68k/include/asm/flat.h
index f3f592d..a97c479 100644
--- a/arch/m68k/include/asm/flat.h
+++ b/arch/m68k/include/asm/flat.h
@@ -19,4 +19,10 @@ static inline int flat_set_persistent(unsigned long relval,
 	return 0;
 }

+#define FLAT_PLAT_INIT(regs) \
+	do { \
+		if (current->mm) \
+			(regs)->d5 = current->mm->start_data; \
+	} while (0)
+
 #endif /* __M68KNOMMU_FLAT_H__ */
diff --git a/arch/m68k/include/asm/processor.h b/arch/m68k/include/asm/processor.h
index a6ce2ec..46672d1 100644
--- a/arch/m68k/include/asm/processor.h
+++ b/arch/m68k/include/asm/processor.h
@@ -131,8 +131,6 @@ extern int handle_kernel_fault(struct pt_regs *regs);
 do {                                                    \
 	(_regs)->pc = (_pc);                            \
 	setframeformat(_regs);                          \
-	if (current->mm)                                \
-		(_regs)->d5 = current->mm->start_data;  \
 	(_regs)->sr &= ~0x2000;                         \
 	wrusp(_usp);                                    \
 } while(0)
-- 
1.9.1