linux-kernel - Re: [RFC][PATCH 0/5] Fixes for abs() usage on 64bit values

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150915052049.GA14215@gmail.com>
Date:	Tue, 15 Sep 2015 07:20:49 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	John Stultz <john.stultz@...aro.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Tejun Heo <tj@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Steven Rostedt (Red Hat)" <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Prarit Bhargava <prarit@...hat.com>,
	Richard Cochran <richardcochran@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Dave Chinner <dchinner@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC][PATCH 0/5] Fixes for abs() usage on 64bit values


* John Stultz <john.stultz@...aro.org> wrote:

> On Mon, Sep 14, 2015 at 6:49 PM, Tejun Heo <tj@...nel.org> wrote:
> > Hello,
> >
> > On Mon, Sep 14, 2015 at 06:05:19PM -0700, John Stultz wrote:
> >> As noted in include/linux/kernel.h:
> >>  "abs() should not be used for 64-bit types (s64, u64, long long)
> >>  - use abs64() for those."
> >>
> >> Unfortunately, there are quite a number of places where abs()
> >> was used w/ 64bit values in the kernel, and the results are
> >> then silently capped to 32-bit values on 32-bit systems.
> >
> > I don't get it.  Why can't we just do the following?
> >
> > #define abs(x)                                                                  \
> > ({                                                                              \
> >          typeof(x) __x = (x);                                                   \
> >          __x < 0 ? -__x : __x;                                                  \
> > })
> >
> 
> Yea. The above make sense to me, but I suspect there's some very
> subtle reason for the existing separated logic.
> But I'd have to defer to akpm for hints on that.

On one hand there's a real cost from abs() bugs: the fact that abs() trims the 
high bits silently led to a (serious) timekeeping bug on 32-bit kernels, that was 
not found for almost 2 years:

  2619d7e9c92d time: Fix timekeeping_freqadjust()'s incorrect use of abs() instead of abs64()

On the other hand, there's literally hundreds of abs() usages in the kernel - I 
think it would be a lot safer to just introduce a build time warning and migrate 
the few affected ones over to abs64() (i.e. what John has done), than to silently 
change semantics in an all-or-nothing fashion, even if arguably many (most?) of 
the 64-bit values passed to abs() are probably bugs.

This has another advantage: we'll see all the bugs that occured so far, and can 
judge their effect on a case by case basis. There's value in that kind of gradual 
approach as well.

Once we've gone through that fixing process (for 1-2 kernel releases) we could 
perhaps do the change and unify abs() and abs64(): users who really want 32-bit 
trimming in the future can do the cast explicitly.

Linus, any preferences?

Thanks,

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