Tại sao AES trong SSE không cung cấp đầy đủ chức năng?

Question

Các Rijndael key schedule procedure liên quan đến RotWord, SubWord, và XOR, tất cả được hỗ trợ bởi _mm_aeskeygenassist_si128:

X3[31:0] ← SRC [127: 96]; 
X2[31:0] ← SRC [95: 64]; 
X1[31:0] ← SRC [63: 32]; 
X0[31:0] ← SRC [31: 0]; 
RCON[31:0] ← ZeroExtend(Imm8[7:0]); 
DEST[31:0] ← SubWord(X1); 
DEST[63:32 ] ← RotWord(SubWord(X1)) XOR RCON; 
DEST[95:64] ← SubWord(X3); 
DEST[127:96] ← RotWord(SubWord(X3)) XOR RCON; 
DEST[VLMAX-1:128] (Unmodified) 

Tuy nhiên, nó không trả lại một phím tròn hoàn chỉnh. Ví dụ, thay vì chỉ đơn giản là thực hiện

DEST[31:0] <- SubWord(X1),

Tôi đoán chúng tôi thực sự nên thực hiện

DEST[31:0]<-RotWord(SubWord(X3)) XOR RCON XOR X0.

Kết quả là, sau _mm_aeskeygenassist_si128, chúng tôi nhà phát triển phải thực hiện thêm một số công việc trước khi khóa tròn được tạo hoàn toàn.

Tại sao SSE không cung cấp quy trình tạo khóa AES hoàn chỉnh?

Answer 1

Xem Key Expansion Using AESKEYGENASSIST (page 23) trong báo cáo AES-NI của Intel. Họ chỉ ra rằng các hướng dẫn có thể được sử dụng như một khối xây dựng cho các kích cỡ khóa khác nhau: 128/192/256. Chúng chỉ hiển thị ví dụ cho 128b, thực hiện công việc bổ sung với lệnh gọi hàm sau mỗi lệnh aeskeygenassist như bạn mô tả.

AESKEYGENASSIST là đã vi mã (ví dụ 13 UOPs trên Skylake vs chỉ 1 cho AESDEC/AESENC (http://agner.org/optimize/)), do đó, có hướng dẫn khác nhau mà làm vài bước cuối cùng mà khác nhau đối với các kích cỡ khác nhau quan trọng sẽ không làm nó chạy nhanh hơn nhiều cách nó hiện đang được triển khai.

Skylake có 1 trên 12 chu kỳ aeskeygenassist thông lượng, nhưng Nehalem có 1 trên 2 chu kỳ, giống như aesenc. Vì vậy, trong Nehalem, tôi đoán họ đã thực hiện nó chủ yếu trong phần cứng chuyên dụng. Đó có thể là một phần khác của giải thích: nhiều bước hơn sẽ chiếm nhiều phần cứng hơn trong việc thực hiện gen đầu tiên, hoặc làm cho lệnh vi mã hóa (mà có lẽ nó không có trong Nehalem) để thực hiện các bước bổ sung với nhiều uops hơn.

Intel rõ ràng không nghĩ rằng thiết lập quan trọng là hiệu suất quan trọng, bởi vì như tôi đã nói họ đã giảm hiệu suất của aeskeygenassist sau Nehalem. (Ngay cả Sandybridge đã có vi mã hóa với thông lượng 1 trên 8 đồng hồ.)

---

Có các hướng dẫn khác nhau cho các phím khác nhau sẽ thực hiện thêm opcodes. Tại thời điểm đó, Intel đã không giới thiệu tiền tố VEX, vì vậy chi tiêu nhiều không gian opcode trên hướng dẫn AES sẽ làm giảm phòng còn lại cho các phần mở rộng trong tương lai. (VEX có rất nhiều không gian mã hóa, chỉ sử dụng một vài mã nhiều bit cho các kết hợp tiền tố bắt buộc hiện tại được sử dụng bởi các hướng dẫn hiện tại.)