New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AES-NI troubles on MS Windows (gcc compiler) #95
Comments
Nope, haven't seen that before, but also didn't try out AES-NI on Windows. |
I suspect memory (non)alignment of 1/ I have included
2/ For dynamic memory allocation I use:
which is some old perl macro/wrapper around malloc |
Yes, it is an alignment issue:
A dirty hack is to use Or should we check
as passing unaligned It might be also nice to have something like |
Another potential source of troubles are libtomcrypt structures like:
where |
Aligning a `struct` member via `attribute(align(<n>))` is not guaranteed to work. Change the approach to use an opaque buffer and always manually align the start pointers of the keys. c.f. DCIT/perl-CryptX#95 Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Can you check whether this fixes the issue? I'm not sure whether there's a better way than doing this in all places that require alignment of struct members... |
Yes, your patch works. I am for merging the patch to libtomcrypt as it is much more robust. Perhaps only add some comment why the code is as it is. |
@sjaeckel UPDATE: This compiler
and the test suite fails the same way as when the alignment is wrong. You can download the gcc in question in |
the gcc where the patch did work was |
Hmm, I built with gcc 13.2.1 and clang 16.0.6 and both are happy with the code as committed ... |
The warning happens with gcc-13.1.0 only when I use |
I'll have another look later! |
This seems to work:
but the |
Perhaps:
|
Hmm, I used |
My guess is that this will work very often, but in the end it's most likely not such a good idea, since we'd also zero-out the upper 4 bits like that ;) |
Well, |
Are you sure? #include <stdio.h>
int main (void) {
size_t N;
void *K;
N = 18446744073709551615ULL; // 0xffffffffffffffff
K = (void*)N;
printf("ptr1=%p\n", K); // ptr1=ffffffffffffffff
K = (void*)((((size_t)K) >> 4) << 4);
printf("ptr2=%p\n", K); // ptr2=fffffffffffffff0
return 0;
} |
omfg ... no, what I wrote was wrong. ... I really shouldn't write comments while doing other stuff 😄 |
TBH I'm not so sure whether I'd prefer to pollute the codebase by using the wrong type or "pollute" it by adding the dependency to a header file that originates from a standard which is legally allowed to drink even in the US... ... but maybe that opinion is also wrong... |
I understand, but here in the "perl world" sooner or later a guy with some esoteric IBM, HP or other legacy stuff will create an issue that my module does not compile on his platform. |
Aligning a `struct` member via `attribute(align(<n>))` is not guaranteed to work. Change the approach to use an opaque buffer and always manually align the start pointers of the keys. c.f. DCIT/perl-CryptX#95 Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Fine like that? |
Aligning a `struct` member via `attribute(align(<n>))` is not guaranteed to work. Change the approach to use an opaque buffer and always manually align the start pointers of the keys. c.f. DCIT/perl-CryptX#95 Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Aligning a `struct` member via `attribute(align(<n>))` is not guaranteed to work. Change the approach to use an opaque buffer and always manually align the start pointers of the keys. c.f. DCIT/perl-CryptX#95 Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
solved by the latest libtomcrypt:develop |
64-bit MS Windows, perl 5.32, compiler: gcc 8.3.0 (= strawberry-perl-5.32.1.1-64bit-portable.zip)
Running
t/cipher_aes.t
crashes duringCrypt::Cipher::AES->new(..)
which turns out to be a crash inaesni_setup
Specifically here:
Not seen this kind of crash on linux.
@sjaeckel any idea?
The text was updated successfully, but these errors were encountered: