[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jK0Br+rzjwU-6yEcjjdtsHB55UwZf9xGMgOTFjbmWFzWA@mail.gmail.com>
Date: Thu, 19 Oct 2017 13:42:03 -0700
From: Kees Cook <keescook@...omium.org>
To: Michael Davidson <md@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
David Miller <davem@...emloft.net>,
Matthew Wilcox <mawilcox@...rosoft.com>,
LKML <linux-kernel@...r.kernel.org>,
"Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH] lib/int_sqrt.c: optimize for small argument values
On Thu, Oct 19, 2017 at 1:31 PM, Michael Davidson <md@...gle.com> wrote:
> int_sqrt() currently takes approximately constant time
> regardless of the value of the argument. By using the
> magnitude of the operand to set the initial conditions
> for the calculation the cost becomes proportional to
> log2 of the argument with the worst case behavior not
> being measurably slower than it currently is.
Maybe a stupid question, but is this function ultimately used by any
crypto that expects it to be constant-time for safety?
Also, is there a specific workload that is meaningfully sped up by this change?
-Kees
>
> Signed-off-by: Michael Davidson <md@...gle.com>
> ---
> lib/int_sqrt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/int_sqrt.c b/lib/int_sqrt.c
> index 1ef4cc344977..8394b0dcecd4 100644
> --- a/lib/int_sqrt.c
> +++ b/lib/int_sqrt.c
> @@ -21,7 +21,7 @@ unsigned long int_sqrt(unsigned long x)
> if (x <= 1)
> return x;
>
> - m = 1UL << (BITS_PER_LONG - 2);
> + m = 1UL << (__fls(x) & ~1UL);
> while (m != 0) {
> b = y + m;
> y >>= 1;
> --
> 2.15.0.rc1.287.g2b38de12cc-goog
>
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists