Skip Menu |
 

From schwim@whatmore.Stanford.EDU Wed May 20 21:08:18 1998
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id VAA18852 for <bugs@RT-11.MIT.EDU>; Wed, 20 May 1998 21:08:18 -0400
Received: from whatmore.Stanford.EDU by MIT.EDU with SMTP
id AA23498; Wed, 20 May 98 21:08:10 EDT
Received: (from schwim@localhost)
by whatmore.Stanford.EDU (8.8.8/8.8.8) id SAA27787;
Wed, 20 May 1998 18:08:15 -0700 (PDT)
Message-Id: <199805210108.SAA27787@whatmore.Stanford.EDU>
Date: Wed, 20 May 1998 18:08:15 -0700 (PDT)
From: Larry Schwimmer <schwim@whatmore.Stanford.EDU>
To: krb5-bugs@MIT.EDU
Subject: krb5-1.0.5: key schedule alignment lib patches

Show quoted text
>Number: 593
>Category: krb5-libs
>Synopsis: key schedule alignment
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed May 20 21:09:00 EDT 1998
>Last-Modified: Fri Sep 14 11:45:45 EDT 2001
>Originator: Larry Schwimmer
>Organization:
Stanford University
Show quoted text
>Release: krb5-1.0.5
>Environment:
Sparc Solaris
Show quoted text
>Description:

Using the krb4 compatibility libraries, the key schedule
routines generated a bus error on the Solaris sparc platform. I
tried compiling under both cc and gcc with various optimization
and debugging levels. The data structure was not word-aligned,
causing the problem.

Show quoted text
>How-To-Repeat:
>Fix:

Two files were affected, lib/crypto/des/f_sched.c and
lib/des425/pcbc_encrypt.c. I realize that the encryption code is
optimized and that it should have as low overhead as possible, but the
patches were needed to make the code function at all. Since the call
in f_sched.c is called only a few times by programs, the overhead of
two memcpy calls should be insignificant.
The other file affected was lib/des425/pcbc_encrypt.c, which
is called regularly by programs using krb4. The patch only adds one
memcpy call, which is turned into inlined assembly by modern
compilers, so it should not add a significant overhead on modern
machines. It also only affects krb4 compatibility code, so it seems
reasonable.
Since the overhead was small, the problem large, and aligned
access tends to be faster, I did not restrict the patch to Solaris
Sparc. (I've tested the code with and without the patch on Solaris
Sparc, Solaris x86, HP-UX, Linux 2.0.x, AIX 4.1, AIX 4.2, IRIX 5.3,
IRIX 6.2, IRIX 6.4, Digital UNIX 3.2c, and Digital UNIX 4.0.)

yours,
Larry Schwimmer
schwim@leland.stanford.edu
Leland Systems Group

--- lib/crypto/des/f_sched.c.orig Fri Feb 6 19:43:25 1998
+++ lib/crypto/des/f_sched.c Mon Apr 13 20:11:23 1998
@@ -216,6 +216,9 @@
mit_des_key_schedule schedule;
{
register unsigned KRB_INT32 c, d;
+ mit_des_key_schedule our_schedule; /* ensures aligned correctly */
+
+ memcpy(our_schedule,schedule,sizeof(our_schedule));

{
/*
@@ -277,7 +280,7 @@
* 48/6 char's/subkey * 16 subkeys/encryption == 128 bytes.
* The schedule must be this big.
*/
- k = (unsigned KRB_INT32 *)schedule;
+ k = (unsigned KRB_INT32 *)our_schedule;
two_bit_shifts = TWO_BIT_SHIFTS;
for (i = 16; i > 0; i--) {
/*
@@ -333,5 +336,7 @@
*k++ = (ltmp & 0xff0000ff) | (rtmp & 0x00ffff00);
}
}
+
+ memcpy(schedule,our_schedule,sizeof(our_schedule));
return (0);
}
--- lib/des425/pcbc_encrypt.c.orig Fri Feb 6 19:43:34 1998
+++ lib/des425/pcbc_encrypt.c Mon Apr 13 20:26:58 1998
@@ -83,11 +83,13 @@
register unsigned KRB_INT32 temp;
register unsigned KRB_INT32 *kp;
register unsigned char *ip, *op;
+ des_key_schedule our_schedule; /* ensure aligned correctly */
+ memcpy(our_schedule,schedule,sizeof(our_schedule));

/*
* Copy the key pointer, just once
*/
- kp = (unsigned KRB_INT32 *)schedule;
+ kp = (unsigned KRB_INT32 *)our_schedule;

/*
* Deal with encryption and decryption separately.
Show quoted text
>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->krb5-unassigned
Responsible-Changed-By: raeburn
Responsible-Changed-When: Fri Sep 14 11:45:40 2001
Responsible-Changed-Why:
reformat/refile
Show quoted text
>Unformatted:
Subject: key schedule alignment
I believe this is not a problem any more. We haven't noticed any
problems on a couple of 64-bit platforms. The key schedule data
structure was changed a while back, which may have improved things.
Even if not, I think it's the responsibility of the callers of these
functions, and the compiler, to ensure that the key schedule structures
are properly aligned.