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]
Date:	Thu, 03 Nov 2011 10:01:09 -0400
From:	John Stultz <john.stultz@...aro.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Yong Zhang <yong.zhang0@...il.com>,
	David Daney <ddaney.cavm@...il.com>
Subject: Re: [PATCH] clocksource: Avoid selecting mult values that might
 overflow when adjusted

On Thu, 2011-11-03 at 14:26 +0100, Thomas Gleixner wrote:
> On Thu, 3 Nov 2011, John Stultz wrote:
> > On Thu, 2011-11-03 at 13:05 +0100, Thomas Gleixner wrote:
> > > On Wed, 2 Nov 2011, John Stultz wrote:
> > > >  
> > > > +	WARN_ONCE(timekeeper.mult+adj >
> > > > +			timekeeper.clock->mult + timekeeper.clock->maxadj,
> > > > +			"Adjusting more then 11%%");
> > > 
> > > Shouldn't we rather limit the update instead of just warn and overflow ?
> > 
> > Well, I'm hesitant to commit to that, just yet. So I figured I'd start
> > with the warning.
> 
> OTOH, we know right there that we might warp 32bit and confuse the
> hell out of timekeeping, which is not a real good thing either.

Oh certainly, but two things:
1) The 11% max is not the actual overflow edge. Its just calculated as
safe. The overflow could as far out as ~22%.

2) This is the first case in however many years I've heard of of mult
overflowing. So before we go changing the NTP code (which is really
terribly complex, but has been working fairly well for awhile) I want to
have some sense that the 11% max adjustment assumption is really
correct.

But maybe I'm being too conservative? If we do limit the adjustment
keeping the warning, I guess we'd know why things blew up on previously
working machines. 

thanks
-john

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ