Omit padding in RC4_KEY on IA-64. The idea behind padding was to reserve

room for aligning of the key schedule itself [specific alignment is
required for future performance improvements], but OpenSSH "abuses"
our API by making copies and restoring RC4_KEY, thus ruining the
alignment and making it impossible to recover the key schedule.
PR: 1114

crypto/rc4/Makefile

@@ -54,7 +54,11 @@ rx86-out.s: asm/rc4-586.pl ../perlasm/x86asm.pl
 rc4-x86_64.s: asm/rc4-x86_64.pl;	$(PERL) asm/rc4-x86_64.pl $@
 
 rc4-ia64.s: asm/rc4-ia64.S
-	$(CC) $(CFLAGS) -E asm/rc4-ia64.S > $@
+	@case `awk '/^#define RC4_INT/{print$$NF}' $(TOP)/include/openssl/opensslconf.h` in \
+	int)	set -x; $(CC) $(CFLAGS) -DSZ=4 -E asm/rc4-ia64.S > $@ ;; \
+	char)	set -x; $(CC) $(CFLAGS) -DSZ=1 -E asm/rc4-ia64.S > $@ ;; \
+	*)	exit 1 ;; \
+	esac
 
 files:
 	$(PERL) $(TOP)/util/files.pl Makefile >> $(TOP)/MINFO

crypto/rc4/asm/rc4-ia64.S

@@ -7,7 +7,7 @@
 // disclaimed.
 // ====================================================================
 
-.ident  "rc4-ia64.S, Version 1.1"
+.ident  "rc4-ia64.S, Version 2.0"
 .ident  "IA-64 ISA artwork by Andy Polyakov <appro@fy.chalmers.se>"
 
 // What's wrong with compiler generated code? Because of the nature of
@@ -27,17 +27,10 @@
 // Legitimate "collisions" do occur within every 256^2 bytes window.
 // Fortunately there're enough free instruction slots to keep prior
 // reference to key[x+1], detect "collision" and compensate for it.
-// All this without sacrificing a single clock cycle:-)
-// Furthermore. In order to compress loop body to the minimum, I chose
-// to deploy deposit instruction, which substitutes for the whole
-// key->data+((x&255)<<log2(sizeof(key->data[0]))). This unfortunately
-// requires key->data to be aligned at sizeof(key->data) boundary.
-// This is why you'll find "RC4_INT pad[512-256-2];" addenum to RC4_KEY
-// and "d=(RC4_INT *)(((size_t)(d+255))&~(sizeof(key->data)-1));" in
-// rc4_skey.c [and rc4_enc.c, where it's retained for debugging
-// purposes]. Throughput is ~210MBps on 900MHz CPU, which is is >3x
-// faster than gcc generated code and +30% - if compared to HP-UX C.
-// Unrolling loop below should give >30% on top of that...
+// All this without sacrificing a single clock cycle:-) Throughput is
+// ~210MBps on 900MHz CPU, which is is >3x faster than gcc generated
+// code and +30% - if compared to HP-UX C. Unrolling loop below should
+// give >30% on top of that...
 
 .text
 .explicit
@@ -48,7 +41,9 @@
 # define ADDP	add
 #endif
 
+#ifndef SZ
 #define SZ	4	// this is set to sizeof(RC4_INT)
+#endif
 // SZ==4 seems to be optimal. At least SZ==8 is not any faster, not for
 // assembler implementation, while SZ==1 code is ~30% slower.
 #if SZ==1	// RC4_INT is unsigned char
@@ -101,45 +96,53 @@ RC4:
 	ADDP	out=0,in3
 	brp.loop.imp	.Ltop,.Lexit-16	};;
 { .mmi;	LDKEY	yy=[key]			// load key->y
-	add	ksch=(255+1)*SZ,key		// as ksch will be used with
-						// deposit instruction only,
-						// I don't have to &~255...
+	add	ksch=SZ,key
 	mov	ar.lc=in1		}
 { .mmi;	mov	key_y[1]=r0			// guarantee inequality
 						// in first iteration
 	add	xx=1,xx
 	mov	pr.rot=1<<16		};;
 { .mii;	nop.m	0
-	dep	key_x[1]=xx,ksch,OFF,8
+	dep	key_x[1]=xx,r0,OFF,8
 	mov	ar.ec=3			};;	// note that epilogue counter
 						// is off by 1. I compensate
 						// for this at exit...
 .Ltop:
-// The loop is scheduled for 3*(n+2) spin-rate on Itanium 2, which
+// The loop is scheduled for 4*(n+2) spin-rate on Itanium 2, which
 // theoretically gives asymptotic performance of clock frequency
-// divided by 3 bytes per seconds, or 500MBps on 1.5GHz CPU. Measured
-// performance however is distinctly lower than 1/4:-( The culplrit
-// seems to be *(out++)=dat, which inadvertently splits the bundle,
-// even though there is M-port available... Unrolling is due...
-// Unrolled loop should collect output with variable shift instruction
-// in order to avoid starvation for integer shifter... It should be
-// possible to get pretty close to theoretical peak...
-{ .mmi;	(p16)	LDKEY	tx[0]=[key_x[1]]		// tx=key[xx]
-	(p17)	LDKEY	ty[0]=[key_y[1]]		// ty=key[yy]	
-	(p18)	dep	rnd[1]=rnd[1],ksch,OFF,8}	// &key[(tx+ty)&255]
+// divided by 4 bytes per seconds, or 400MBps on 1.6GHz CPU. This is
+// for sizeof(RC4_INT)==4. For smaller RC4_INT STKEY inadvertently
+// splits the last bundle and you end up with 5*n spin-rate:-(
+// Originally the loop was scheduled for 3*n and relied on key
+// schedule to be aligned at 256*sizeof(RC4_INT) boundary. But
+// *(out++)=dat, which maps to st1, had same effect [inadvertent
+// bundle split] and holded the loop back. Rescheduling for 4*n
+// made it possible to eliminate dependence on specific alignment
+// and allow OpenSSH keep "abusing" our API. Reaching for 3*n would
+// require unrolling, sticking to variable shift instruction for
+// collecting output [to avoid starvation for integer shifter] and
+// copying of key schedule to controlled place in stack [so that
+// deposit instruction can serve as substitute for whole
+// key->data+((x&255)<<log2(sizeof(key->data[0])))]...
 { .mmi;	(p19)	st1	[out]=dat[3],1			// *(out++)=dat
 	(p16)	add	xx=1,xx				// x++
-	(p16)	cmp.ne.unc p20,p21=key_x[1],key_y[1]	};;
+	(p18)	dep	rnd[1]=rnd[1],r0,OFF,8	}	// ((tx+ty)&255)<<OFF
+{ .mmi;	(p16)	add	key_x[1]=ksch,key_x[1]		// &key[xx&255]
+	(p17)	add	key_y[1]=ksch,key_y[1]	};;	// &key[yy&255]	
+{ .mmi;	(p16)	LDKEY	tx[0]=[key_x[1]]		// tx=key[xx]
+	(p17)	LDKEY	ty[0]=[key_y[1]]		// ty=key[yy]	
+	(p16)	dep	key_x[0]=xx,r0,OFF,8	}	// (xx&255)<<OFF
+{ .mmi;	(p18)	add	rnd[1]=ksch,rnd[1]		// &key[(tx+ty)&255]
+	(p16)	cmp.ne.unc p20,p21=key_x[1],key_y[1] };;
 { .mmi;	(p18)	LDKEY	rnd[1]=[rnd[1]]			// rnd=key[(tx+ty)&255]
-	(p16)	ld1	dat[0]=[inp],1			// dat=*(inp++)
-	(p16)	dep	key_x[0]=xx,ksch,OFF,8	}	// &key[xx&255]
+	(p16)	ld1	dat[0]=[inp],1		}	// dat=*(inp++)
 .pred.rel	"mutex",p20,p21
 { .mmi;	(p21)	add	yy=yy,tx[1]			// (p16)
 	(p20)	add	yy=yy,tx[0]			// (p16) y+=tx
 	(p21)	mov	tx[0]=tx[1]		};;	// (p16)
 { .mmi;	(p17)	STKEY	[key_y[1]]=tx[1]		// key[yy]=tx
 	(p17)	STKEY	[key_x[2]]=ty[0]		// key[xx]=ty
-	(p16)	dep	key_y[0]=yy,ksch,OFF,8	}	// &key[yy&255]
+	(p16)	dep	key_y[0]=yy,r0,OFF,8	}	// &key[yy&255]
 { .mmb;	(p17)	add	rnd[0]=tx[1],ty[0]		// tx+=ty
 	(p18)	xor	dat[2]=dat[2],rnd[1]		// dat^=rnd
 	br.ctop.sptk	.Ltop			};;

crypto/rc4/rc4.h

@@ -72,10 +72,6 @@ typedef struct rc4_key_st
 	{
 	RC4_INT x,y;
 	RC4_INT data[256];
-#if defined(__ia64) || defined(__ia64__) || defined(_M_IA64)
-	/* see crypto/rc4/asm/rc4-ia64.S for further details... */
-	RC4_INT pad[512-256-2];
-#endif
 	} RC4_KEY;
 
  

crypto/rc4/rc4_enc.c

@@ -77,10 +77,6 @@ void RC4(RC4_KEY *key, unsigned long len, const unsigned char *indata,
         x=key->x;     
         y=key->y;     
         d=key->data; 
-#if defined(__ia64) || defined(__ia64__) || defined(_M_IA64)
-	/* see crypto/rc4/asm/rc4-ia64.S for further details... */
-	d=(RC4_INT *)(((size_t)(d+255))&~(sizeof(key->data)-1));
-#endif
 
 #if defined(RC4_CHUNK)
 	/*

crypto/rc4/rc4_skey.c

@@ -93,10 +93,6 @@ void RC4_set_key(RC4_KEY *key, int len, const unsigned char *data)
         unsigned int i;
         
         d= &(key->data[0]);
-#if defined(__ia64) || defined(__ia64__) || defined(_M_IA64)
-	/* see crypto/rc4/asm/rc4-ia64.S for further details... */
-	d=(RC4_INT *)(((size_t)(d+255))&~(sizeof(key->data)-1));
-#endif
         key->x = 0;     
         key->y = 0;     
         id1=id2=0;