[openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-08-24 Thread Matt Caswell via RT
Resolved by overlapping buffer checks. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-06-15 Thread Salz, Rich via RT
Not defined means we make no guarantees. OpenSSL can depend on what it knows to be true. In the next release we can revisit this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted -- openssl-dev mailing list To

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-06-15 Thread David Benjamin via RT
I don't think that will work. The SSL code uses in-place buffers extensively, so in == out definitely needs to be defined. The question is only whether out < in is also acceptable. Either way, for BoringSSL, I've gone ahead and tightened our aliasing constraints to forbid out < in and require

[openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-06-15 Thread Rich Salz via RT
I think for now, we just note this in the documentation: behavior for overlapping buffers, and even in-place buffers, is not defined. It's like memcpy() vs memmove(). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted --

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-06-07 Thread Brian Smith via RT
Brian Smith wrote: > It seems that 32-bit ARM has the same limitation as x86 that the input and > output pointers must match or the input and output buffers must not overlap > at all. I'm not sure which ARM code path (NEON or non-NEON, or both) has > this issue. Just to

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-04-16 Thread Brian Smith via RT
It seems that 32-bit ARM has the same limitation as x86 that the input and output pointers must match or the input and output buffers must not overlap at all. I'm not sure which ARM code path (NEON or non-NEON, or both) has this issue. Cheers, Brian -- https://briansmith.org/ -- Ticket here:

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-10 Thread David Benjamin
The current state is that, as far as I can tell, overlapping requirements are undocumented (or is it somewhere and I missed it?) and, for ChaCha, architecture-specific. I think something certainly needs to be done. Either changing chacha-x86.pl and allowing any out <= in overlap, or declaring that

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-10 Thread David Benjamin via RT
The current state is that, as far as I can tell, overlapping requirements are undocumented (or is it somewhere and I missed it?) and, for ChaCha, architecture-specific. I think something certainly needs to be done. Either changing chacha-x86.pl and allowing any out <= in overlap, or declaring that

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-04 Thread Andy Polyakov
>> Fear is irrational and destructive feeling. Having faith that world is >> better than that it nothing but healthy :-) What I'm saying is that >> let's put a little bit more substance into discourse. Would anybody >> consider it *sane* programming practice to rely on partially overlapping >>

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-04 Thread Viktor Dukhovni
> On Mar 4, 2016, at 7:24 AM, Andy Polyakov via RT wrote: > > Fear is irrational and destructive feeling. Having faith that world is > better than that it nothing but healthy :-) What I'm saying is that > let's put a little bit more substance into discourse. Would anybody >

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-04 Thread Andy Polyakov via RT
>>> If the other EVP ciphers universally allow this then I think we must >> treat this >>> as a bug, because people may be relying on this behaviour. There is also >>> sporadic documentation in lower-level APIs (AES source and des.pod) that >> the >>> buffers may overlap. >>> >>> If it's

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-04 Thread emi...@openssl.org via RT
On Fri, Mar 4, 2016 at 12:48 PM Andy Polyakov via RT wrote: > > If the other EVP ciphers universally allow this then I think we must > treat this > > as a bug, because people may be relying on this behaviour. There is also > > sporadic documentation in lower-level APIs (AES

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-04 Thread Emilia Käsper
On Fri, Mar 4, 2016 at 12:48 PM Andy Polyakov via RT wrote: > > If the other EVP ciphers universally allow this then I think we must > treat this > > as a bug, because people may be relying on this behaviour. There is also > > sporadic documentation in lower-level APIs (AES

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-04 Thread Andy Polyakov via RT
> If the other EVP ciphers universally allow this then I think we must treat > this > as a bug, because people may be relying on this behaviour. There is also > sporadic documentation in lower-level APIs (AES source and des.pod) that the > buffers may overlap. > > If it's inconsistent then, at

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-01 Thread Andy Polyakov
> I'm unclear on what EVP_CIPHER's interface guarantees are, but our EVP_AEAD > APIs are documented to allow in/out buffers to alias as long as out is <= > in. This matches what callers might expect from a naive implementation. > > Our AES-GCM EVP_AEADs, which share code with OpenSSL, have tended

[openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-01 Thread Emilia Käsper via RT
If the other EVP ciphers universally allow this then I think we must treat this as a bug, because people may be relying on this behaviour. There is also sporadic documentation in lower-level APIs (AES source and des.pod) that the buffers may overlap. If it's inconsistent then, at the very least,

[openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

2016-03-01 Thread David Benjamin via RT
I'm unclear on what EVP_CIPHER's interface guarantees are, but our EVP_AEAD APIs are documented to allow in/out buffers to alias as long as out is <= in. This matches what callers might expect from a naive implementation. Our AES-GCM EVP_AEADs, which share code with OpenSSL, have tended to match