linux-kernel - Re: [PATCH] crypto: xor - avoid division by zero crash

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]

Date:   Sun, 24 Jan 2021 21:38:30 +0100
From:   Helge Deller <deller@....de>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Douglas Anderson <dianders@...omium.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:PARISC ARCHITECTURE" <linux-parisc@...r.kernel.org>
Subject: Re: [PATCH] crypto: xor - avoid division by zero crash

On 1/24/21 3:30 PM, Ard Biesheuvel wrote:
> On Sun, 24 Jan 2021 at 15:28, Helge Deller <deller@....de> wrote:
>>
>> On some of my parisc machines, this patch c055e3eae0f1 ("crypto: xor -
>> use ktime for template benchmarking") triggers a dividy-by-zero
>> exception because "min" becomes zero, which then leads to a kernel
>> crash.
>>
>> It's not clear yet, why I see the issue only on some machines. At least
>> on those the measured time to run the xor speed tests becomes zero
>> nanoseconds. Maybe it's because gcc-10 optimizes the speed test out, or
>> because of some other changes in the time keeping routines.
>>
>> In either case, the kernel should not crash.
>>
>> This patch adds a workaround by reporting such cases with a kernel
>> warning and continues as if the xor tests would have run in 1 ns.
>>
>> Signed-off-by: Helge Deller <deller@....de>
>> Cc: stable@...r.kernel.org # 5.10+
>>
>> ---
>>
>> diff --git a/crypto/xor.c b/crypto/xor.c
>> index eacbf4f93990..3639341bac7e 100644
>> --- a/crypto/xor.c
>> +++ b/crypto/xor.c
>> @@ -100,6 +100,8 @@ do_xor_speed(struct xor_block_template *tmpl, void *b1, void *b2)
>>                         mb();
>>                 }
>>                 diff = ktime_sub(ktime_get(), start);
>> +               if (WARN_ON(diff == 0))
>> +                       diff = 1;
>>                 if (diff < min)
>>                         min = diff;
>>         }
>
> This should already be fixed in mainline - please check whether that
> fix works for you.

Yes, it's basically the same fix and a good step.
It fixes the kernel crash at least, but it's still strange that
the timing calculation will be wrong.

Helge