linux-kernel - [RFC PATCH v1] mips: Use unsigned int when reading CP0 registers

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-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jul 2015 10:44:30 +1200
From:	Chris Packham <judge.packham@...il.com>
To:	linux-mips@...ux-mips.org
Cc:	Daniel Schwierzeck <daniel.schwierzeck@...il.com>,
	Chris Packham <judge.packham@...il.com>,
	"Steven J. Hill" <Steven.Hill@...tec.com>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	linux-kernel@...r.kernel.org, James Hogan <james.hogan@...tec.com>,
	Markos Chandras <markos.chandras@...tec.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Paul Burton <paul.burton@...tec.com>
Subject: [RFC PATCH v1] mips: Use unsigned int when reading CP0 registers

Update __read_32bit_c0_register() and __read_32bit_c0_ctrl_register() to
use "unsigned int res;" instead of "int res;". There is little reason to
treat these register values as signed. They are either counters (which
by definition are unsigned) or are made up of various bit fields to be
interpreted as per the CPU datasheet.

Signed-off-by: Chris Packham <judge.packham@...il.com>

---
This has come up via u-boot[1] which sync's asm/mipsregs.h with the
kernel. In u-boots case the value read from read_c0_count() is assigned
to an unsigned long [2] which triggers a sign extension and causes a
bug.

U-boot should probably be more explicit about the types used for the
timer_read_counter() API but that aside is there any reason to treat
these values as signed integers? A quick grep around the arch/mips makes
me thing that there may be some bugs lurking when read_c0_count() starts
to yield a negative value but I haven't really explored any of them.

I also notice that read_32bit_cp1_register has a similar issue. I
haven't touched it at this stage but it probably makes sense to do so
for consistency if the CP0 macros are changed. Looking at the users of
read_32bit_cp1_register() it's probably less of an issue.

Thanks,
Chris
--
[1] - http://lists.denx.de/pipermail/u-boot/2015-July/219086.html
[2] - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/mips/cpu/time.c#l11

 arch/mips/include/asm/mipsregs.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index c5b0956..54a942f 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -932,7 +932,7 @@ do {								\
  */

 #define __read_32bit_c0_register(source, sel)				\
-({ int __res;								\
+({ unsigned int __res;							\
 	if (sel == 0)							\
 		__asm__ __volatile__(					\
 			"mfc0\t%0, " #source "\n\t"			\
@@ -1014,7 +1014,7 @@ do {									\
  * On RM7000/RM9000 these are uses to access cop0 set 1 registers
  */
 #define __read_32bit_c0_ctrl_register(source)				\
-({ int __res;								\
+({ unsigned int __res;							\
 	__asm__ __volatile__(						\
 		"cfc0\t%0, " #source "\n\t"				\
 		: "=r" (__res));					\
-- 
2.5.0.rc0

--
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/