Dlaczego AES w SSE nie zapewnia pełnej funkcjonalności?

Question

Rijndael key schedule procedure polega RotWord, SubWord i XOR, które są obsługiwane przez _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) 

jednak nie zwraca pełną klucz okrągły. Na przykład, zamiast po prostu wykonując

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

Chyba powinniśmy wykonują

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

W związku z tym, po, programiści muszą wykonać dodatkową pracę, zanim klucz okrągły zostanie całkowicie wygenerowany.

Dlaczego SSE nie zapewnia pełnej procedury generowania klucza AES?

Answer 1

Zobacz Key Expansion Using AESKEYGENASSIST (page 23) w białej księdze firmy Intel poświęconej AES-NI. Podkreślają, że instrukcja może być używana jako element konstrukcyjny dla różnych rozmiarów kluczy: 128/192/256. Pokazują one tylko przykład dla 128b, wykonując dodatkową pracę z wywołaniem funkcji po każdej opisanej aeskeygenassist instrukcji.

AESKEYGENASSIST jest już mikro-zakodowane (np 13 UOPs na Skylake vs. tylko 1 na AESDEC/AESENC (http://agner.org/optimize/)), więc mają różne instrukcje, które wykonują kilka ostatnich kroków, które są różne dla różnych kluczowych rozmiarach nie miałoby działa znacznie szybciej niż dotychczas.

Skylake ma przepustowość 1 na 12 cykli aeskeygenassist, ale Nehalem miał 1 na 2 cykle, taki sam jak aesenc. Tak więc w Nehalem, domyślam się, że zaimplementowali go głównie w dedykowanym sprzęcie. Prawdopodobnie jest to druga część wyjaśnienia: więcej kroków wymagałoby więcej sprzętu w implementacji pierwszej generacji lub uczyniłoby tę instrukcję mikro-zakodowaną (co prawdopodobnie nie było w Nehalem), aby wykonać dodatkowe czynności z większą ilością ubrań.

Intel oczywiście nie uważa, że ​​kluczowa konfiguracja jest krytyczna dla wydajności, ponieważ, jak powiedziałem, zmniejszyły one wydajność po aeskeygenassist po Nehalem. (Nawet gdyby microcoded Sandy Bridge z przepustowości 1 za 8 zegara.)

---

uwzględniając różne instrukcje dla różnych keysizes wziąłby więcej opcodes. W tym momencie Intel nie wprowadził jeszcze prefiksów VEX, więc wydając więcej miejsca na kody w instrukcjach AES, zmniejszyłoby to ilość miejsca na przyszłe rozszerzenia. (VEX ma mnóstwo dostępnej przestrzeni kodowania, używając tylko kilku kodów wielobitowych dla istniejących kombinacji obowiązkowych prefiksów używanych przez bieżące instrukcje.)