Thanks, patch applied.
Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
- OpenSSL assembler modules are maintained as dual-ABI, i.e. suitable
for both Unix and Win64;
OK. I will follow the way like that in aes-x86_64.pl to deal with ABI
issue.
Oh! Currently x86_64-xlate.pl doesn't handle 3 operand instructions, so
some SIMD instructions can't be handled. Some
Hi guys,
This is the HASH_BLOCK_DATA_ORDER (../crypto/sha/sha_locl.h) function prototype
:
static void HASH_BLOCK_DATA_ORDER (SHA_CTX *c, const void *p, size_t num)
As I have mentioned before in a previous thread, I am trying to modify this
function to use my own code in my crappy embedded
I doubt the OS vendors would bother
to enable an engine by default, testing of the possible
configurations is expensive and the costs of support calls if they
mess up makes autodetecting the engine to use a very unattractive
proposition.
One can discuss loading selected engines by
Processing unaligned data in an aligned fashion always requires some
data copying.
There's two different problems, each with a slightly different solution.
#1: input data must be word-aligned but can be processed per byte.
Assume wordsize=8, then an unaligned data input of length = 21 can be
On Wed, 2008-12-10 at 15:56 +0800, Andy Polyakov wrote:
- and $-16, %rdx is unacceptable in this context. The relevant
interface is exposed to end-user and we have to reserve for possibility
that key schedule is memcpy-ed to location with alternative alignment;
Does there any other
On Wed, 2008-12-10 at 16:01 +0800, Andy Polyakov wrote:
I doubt the OS vendors would bother
to enable an engine by default, testing of the possible configurations is
expensive and the costs of support calls if they mess up makes
autodetecting the engine to use a very unattractive
On Wed, 2008-12-10 at 17:22 +0800, Andy Polyakov wrote:
- OpenSSL assembler modules are maintained as dual-ABI, i.e. suitable
for both Unix and Win64;
OK. I will follow the way like that in aes-x86_64.pl to deal with ABI
issue.
Oh! Currently x86_64-xlate.pl doesn't handle 3 operand
On Wed, 2008-12-10 at 15:56 +0800, Andy Polyakov wrote:
Implementation aiming to complement interface exposed by crypto/aes/asm
should allow for non-16-byte-aligned key schedule. Period. One can use
movups, or check alignment and choose between movups and movaps code
paths, or copy key
