linux-kernel - Re: [RFC PATCH] ARM: Use generic BUG() handler

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]

Date:	Wed, 2 Mar 2011 10:59:50 +0000
From:	Dave Martin <dave.martin@...aro.org>
To:	Simon Glass <sjg@...omium.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Phil Carmody <ext-phil.2.carmody@...ia.com>,
	Tony Lindgren <tony@...mide.com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-kernel@...r.kernel.org, Rabin Vincent <rabin@....in>,
	Alexander Shishkin <virtuoso@...nd.org>,
	Mikael Pettersson <mikpe@...uu.se>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Joe Perches <joe@...ches.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH] ARM: Use generic BUG() handler

On Tue, Mar 01, 2011 at 08:34:37AM -0800, Simon Glass wrote:

[...]

> 
> It seems I am lucky with the gcc I am using. I would have thought this
> would be a pretty fundamental feature, but yes I did notice that %c
> wasn't used anywhere.
> 
> Would this kernel feature be acceptable as a selectable config option
> on ARM then?
> 
> Thanks,
> Simon

+/* A suitable undefined instruction to use for ARM bug handling */
+#define BUG_INSTR ".word 0xec000000"

^ This needs to be changed, since it's not an architecturally
undefined encoding -- i.e., it may get used in the future to
mean something real.

See arch/arm/kernel/{ptrace,kprobes}.c for examples of
suitable encodings.

Rather than relying on the %c inline asm feature, can we work
around it?

Since we are writing a macro anyway, we can paste most of the
arguments in when the macro is expanded, rather than relying on
the inline assembler to do it.

This works for everything except sizeof (struct bug_entry)
which the preprocessor obviously can't understand.  But I suspect
we don't really need that: we need to keep the directives that
generate the bug entry in sync with the definition of struct bug_entry
anyway (don't we?) -- so the amount of extra padding needed is
currently zero and should always be a constant.

So, maybe something like this would work:

(Note -- I haven't tested this!)

+
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+#define BUG() __BUG(__FILE__, __LINE__, BUG_INSTR)
+#define __BUG(__file, __line, __bug_instr)			\
+do {								\
+	asm volatile("1:\t" __bug_instr "\n"		q	\
+		     ".pushsection .rodata.str, \"a\"\n"	\
+		     "2:\t.asciz \"" #__file "\"\n"		\
+		     ".popsection\n"				\ 
+		     ".pushsection __bug_table,\"a\"\n"		\
+		     "3:\t.word 1b, 2b\n"			\
+		     "\t.hword " #__line ", 0\n"		\
+		     ".popsection"				\
+	unreachable();						\
+} while (0)

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/