I tested something similar, I tried to load data at address 0xXXXXXXX1 using lxvd2x and it loaded it properly.
On Tue, Jun 30, 2020 at 12:35 PM Jeffrey Walton <[email protected]> wrote: > On Tue, Jun 30, 2020 at 5:29 AM Jeffrey Walton <[email protected]> wrote: > > > > On Tue, Jun 30, 2020 at 5:14 AM Maamoun TK <[email protected]> > wrote: > > > > > > Patch implementation benchmark for GCM_AES (Tested on POWER8): > > > little-endian: > > > - Encrypt x~17.5 of nettle C implementation > > > - Decrypt x~17.5 of nettle C implementation > > > - Update x~30 of nettle C implementation > > > big-endian: > > > - Encrypt x~18.5 of nettle C implementation > > > - Decrypt x~18.5 of nettle C implementation > > > - Update x~28.5 of nettle C implementation > > ... > > > > One small comment for aes_encrypt and aes_decrypt... src and dst are > > usually user supplied buffers. Using lxvd2x to load a vector may > > produce incorrect results if the user is feeding a stream to an > > encryptor or decryptor that is not naturally aligned to that of an > > unsigned int. (On the other hand, Nettle controls the round keys array > > so lxvd2x should be fine.) > > > > Instead of lxvd2x and friends for the user's buffers you should > > consider using lvx and doing the lvsl thing to fix the data in the > > registers. > > In fact, you might want to add a test case like this: > > uint8_t plain[19] = {0,1, ..., 17, 18}; > uint8_t cipher[16], recover[16]; > > Then send plain, plain+1, plain+2 and plain+3 into the encryptor and > see if it round trips. lxvd2x will choke even on POWER9 because two of > the tests will not even be naturally aligned for a byte. > > Jeff > _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
