linux-kernel - Re: [PATCH 2/3] crypto: X25519 core functions for ppc64le

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]

Date: Wed, 15 May 2024 08:58:31 -0500
From: Danny Tsen <dtsen@...ux.ibm.com>
To: Andy Polyakov <appro@...ptogams.org>, linux-crypto@...r.kernel.org
Cc: herbert@...dor.apana.org.au, leitao@...ian.org, nayna@...ux.ibm.com,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        mpe@...erman.id.au, ltcgcw@...ux.vnet.ibm.com, dtsen@...ibm.com
Subject: Re: [PATCH 2/3] crypto: X25519 core functions for ppc64le

Hi Andy,

Thanks for the info.  I should be able to do it.  I was hoping an 
assembly guru like you can show me some tricks here if there is :)

Thanks.

-Danny

On 5/15/24 8:33 AM, Andy Polyakov wrote:
>>> +static void cswap(fe51 p, fe51 q, unsigned int bit)
>>> +{
>>> +    u64 t, i;
>>> +    u64 c = 0 - (u64) bit;
>>> +
>>> +    for (i = 0; i < 5; ++i) {
>>> +        t = c & (p[i] ^ q[i]);
>>> +        p[i] ^= t;
>>> +        q[i] ^= t;
>>> +    }
>>> +}
>>
>> The "c" in cswap stands for "constant-time," and the problem is that 
>> contemporary compilers have exhibited the ability to produce 
>> non-constant-time machine code as result of compilation of the above 
>> kind of technique. The outcome is platform-specific and ironically 
>> some of PPC code generators were observed to generate "most" 
>> non-constant-time code. "Most" in sense that execution time 
>> variations would be most easy to catch.
>
> Just to substantiate the point, consider 
> https://godbolt.org/z/faYnEcPT7, and note the conditional branch in 
> the middle of the loop, which flies in the face of constant-time-ness. 
> In case you object 'bit &= 1' on line 7 in the C code. Indeed, if you 
> comment it out, the generated code will be fine. But the point is that 
> the compiler is capable of and was in fact observed to figure out that 
> the caller passes either one or zero and generate the machine code in 
> the assembly window. In other words 'bit &= 1' is just a reflection of 
> what the caller does.
>
>> ... the permanent solution is to do it in assembly. I can put 
>> together something...
>
> Though you should be able to do this just as well :-) So should I or 
> would you?
>
> Cheers.
>