Re: [PATCH v3] crypto: more robust crypto_memneq

2013-12-05 Thread Herbert Xu
On Wed, Nov 27, 2013 at 01:54:15PM +0100, Daniel Borkmann wrote: > On 11/26/2013 10:44 PM, Cesar Eduardo Barros wrote: > >Em 26-11-2013 17:27, Daniel Borkmann escreveu: > >>On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote: > >>>Compile-tested on x86_64. > >> > >>Actually with yet another version,

Re: [PATCH v3] crypto: more robust crypto_memneq

2013-11-27 Thread Daniel Borkmann
On 11/26/2013 10:44 PM, Cesar Eduardo Barros wrote: Em 26-11-2013 17:27, Daniel Borkmann escreveu: On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote: Compile-tested on x86_64. Actually with yet another version, I hoped that the "compile-tested"-only statement would eventually disappear, ohh

Re: [PATCH v3] crypto: more robust crypto_memneq

2013-11-26 Thread Cesar Eduardo Barros
Em 26-11-2013 17:27, Daniel Borkmann escreveu: On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote: Compile-tested on x86_64. Actually with yet another version, I hoped that the "compile-tested"-only statement would eventually disappear, ohh well. ;) I did compile test each version ;-) includ

Re: [PATCH v3] crypto: more robust crypto_memneq

2013-11-26 Thread Daniel Borkmann
On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote: Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a dummy inline assembly (based on RELOC_HIDE

[PATCH v3] crypto: more robust crypto_memneq

2013-11-25 Thread Cesar Eduardo Barros
Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a dummy inline assembly (based on RELOC_HIDE) to block the problematic kinds of optimization, whil