linux-kernel - Re: [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-prev] [day] [month] [year] [list]

Message-ID: <20150715100503.GA22385@linux-mips.org>
Date:	Wed, 15 Jul 2015 12:05:03 +0200
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	Chris Packham <judge.packham@...il.com>
Cc:	linux-mips@...ux-mips.org,
	Daniel Schwierzeck <daniel.schwierzeck@...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>,
	Paul Burton <paul.burton@...tec.com>
Subject: Re: [RFC PATCH v1] mips: Use unsigned int when reading CP0 registers

On Wed, Jul 15, 2015 at 10:44:30AM +1200, Chris Packham wrote:

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

Known issue but I've always been concerned about math with cycle values
like:

  unsigned int now, timeout = read_c0_counter() + a_bit_of_time;

  waste_some_time();

  if (timeout - read_c0_counter() < 0)
	do_timeout_stuff();

Which now with both variables being unsigned would yield a positive value
thus the if would never be taken.  This particular construction GCC would
warn about but there are other, constructs that wouldn't trigger a warning.

I don't even want to think about what C type propagation rules say about
mixing signed and unsigned types.  Whenever such knowledge is required
to figure out what a piece of code is doing it probably should be considered
broken anyway - but the mess resulting from unwanted sign is no better!

Anyway, I've queued your patch for 4.3.  Thanks!

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

I've cooked up a patch for read_32bit_cp1_register and queued it for 4.3.

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