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

[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 the very least, we must document that it
>> is not
>>> allowed.
>>
>> I'd like to argue that EVP is not place to provide any guarantees about
>> partially overlapping buffers. Even though all current ciphers process
>> data in ascending address order, we shouldn't make assumption that there
>> won't be one that processes data in reverse order.
> 
> 
> I'm afraid that, since we haven't documented it, the world may already have
> made that assumption.

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
buffers in *general* case? I.e. without actually *knowing* (as opposite
to *assuming*) what's gong on? [Control question: does compiler
guarantee order of references to memory?] As said in last message I
don't consider it sane and even consider it natural [which means that
I'd expect majority to not consider it sane too].

Once again, I'm not saying that nothing would be done, I simply want to
figure out where does line go. From my personal view point I'd say that
nothing *has to* be done, but it's just me. You seem to say that we're
obliged to support partially overlapping buffers. My question then is
*any* overlap, *any* cost? Shall we settle for simply writing down that
application developer may not rely on partially overlapping buffers? If
so, do we fix the modules in question arguing that this quality might be
desirable in different context [where modules in question can be used]?



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted