linux-kernel - RE: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

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]

Message-ID: <VI1PR0501MB2461D0661B3417EC9251703AC5E70@VI1PR0501MB2461.eurprd05.prod.outlook.com>
Date:   Sun, 4 Sep 2016 06:40:06 +0000
From:   Liav Rehana <liavr@...lanox.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "john.stultz@...aro.org" <john.stultz@...aro.org>,
        Noam Camus <noamca@...lanox.com>,
        Elad Kanfi <eladkan@...lanox.com>
Subject: RE: [PATCH] Fix chance of sign extension to nsec after its msb is set
 during calculation.

Hi Thomas,

The root of the problem is that in case the multiplication of delta and tkr->mult in the line that I've changed
is too big that the MSB of the result is set, then the shift will cause an unwanted sign extension.

That sign extension will be avoided completely if the variable nsec was unsigned (u64 instead of s64), so I
think the correct solution for this is to change the type of nsec to u64.

Do you agree ?
If not, what is the reason for it being of s64 type in the first place ?
Is there any place where we want the nsec variable to contain a negative value ?
Moreover, how can we cope with the sign extension problems in this case ?

Thanks,
Liav.

-----Original Message-----
From: Thomas Gleixner [mailto:tglx@...utronix.de] 
Sent: Friday, September 02, 2016 9:31 PM
To: Liav Rehana <liavr@...lanox.com>
Cc: linux-kernel@...r.kernel.org; john.stultz@...aro.org; Noam Camus <noamca@...lanox.com>; Elad Kanfi <eladkan@...lanox.com>
Subject: Re: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

On Fri, 2 Sep 2016, Thomas Gleixner wrote:
> On Thu, 1 Sep 2016, Liav Rehana wrote:
> > From: Liav Rehana <liavr@...lanox.com>
> > 
> > During the calculation of the nsec variable, "delta * tkr->mult" may 
> > cause overflow to the msb, if the suspended time is too long.
> > In that case, we need to guarantee that the variable will not go 
> > through a sign extension during its shift, and thus it will result 
> > in a much higher value - close to the larget value of 64 bits.
> > The following commit fixes this problem, which causes the following bug:
> > Trying to connect through ftp to the os after a long enough 
> > suspended time will cause the nsec variable to get a much higher 
> > value after its shift because of sign extension, and thus the loop 
> > that follows some instructions afterwards, implemented in the inline 
> > function __iter_div_u64_rem, will take too long.
> > 
> > Signed-off-by: Liav Rehana <liavr@...lanox.com>
> > ---
> >  kernel/time/timekeeping.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c 
> > index 479d25c..ddf56a5 100644
> > --- a/kernel/time/timekeeping.c
> > +++ b/kernel/time/timekeeping.c
> > @@ -305,7 +305,7 @@ static inline s64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
> >  	s64 nsec;
> >  
> >  	nsec = delta * tkr->mult + tkr->xtime_nsec;
> > -	nsec >>= tkr->shift;
> > +	nsec = ((u64) nsec) >> tkr->shift;
> 
> This typecast is just a baindaid. What happens if you double the suspend time?
> The multiplication will simply overflow. So the proper fix is to 
> sanity check delta and do multiple conversions if delta is big enough. 
> Preferrably this happens somewhere at the call site and not in this hotpath function.

As a side note. John, why is that stuff unsigned at all? Shouldn't we use
u64 for all of this?

Thanks,

	tglx