RFR: 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) [v2]

[Martin Balao]

On Wed, 24 Apr 2024 00:21:40 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose a fix for 8330611.
>> 
>> To avoid an out of bounds memory read when the input's size is not multiple of the block size, we read the plaintext/ciphertext tail in 8, 4, 2 and 1 byte batches depending on what it is guaranteed to be available by 'len_reg'. This behavior replaces the read of 16 bytes of input upfront and later discard of spurious data.
>> 
>> While we add 3 extra instructions + 3 extra memory reads in the worst case —to the same cache line probably—, the performance impact of this fix should be low because it only occurs at the end of the input and when its length is not multiple of the block size.
>> 
>> A reliable test case for this bug is hard to develop because we would need accurate heap allocation. The fact that spuriously read data is silently discarded most of the time makes this bug harder to observe. No regressions have been observed in the compiler/codegen/aes jtreg category. Additionally, we verified the fix manually with the debugger.
>> 
>> This work is in collaboration with @franferrax .
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid register conflict in Windows.
>   
>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

We changed to `r15` the register used for the tail, so we avoid conflicts in Windows.

Code generated:

   0x7fffe4730bb2:	test   $0x8,%r8b
   0x7fffe4730bb6:	je     0x7fffe4730bd3
   0x7fffe4730bbc:	vpextrq $0x0,%xmm0,%r15
   0x7fffe4730bc2:	xor    (%rdi,%r12,1),%r15
   0x7fffe4730bc6:	mov    %r15,(%rsi,%r12,1)
   0x7fffe4730bca:	vpsrldq $0x8,%xmm0,%xmm0
   0x7fffe4730bcf:	add    $0x8,%r12d
   ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18849#issuecomment-2073719278