From owner-freebsd-alpha Tue Mar 27 18:11: 3 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 60E4137B719; Tue, 27 Mar 2001 18:11:00 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2S2AoG72706; Tue, 27 Mar 2001 18:10:50 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 27 Mar 2001 18:10:30 -0800 (PST) From: John Baldwin To: John Baldwin Subject: Re: dump(8) (vfs_object_create() panics: found the problem) Cc: obrien@FreeBSD.org, alpha@FreeBSD.org, Andrew Gallatin , Mark Murray Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 28-Mar-01 John Baldwin wrote: > > On 27-Mar-01 Mark Murray wrote: >>> Ok, as I said earlier, only the pointer to the vnop function table is >>> spammed, the rest of the vnode is ok. I tracked this down to the big >>> /dev/random overhaul commits of March 11. Removing 'device random' >>> from my kernel gets rid of the panic but breaks ssh. :( A kernel just >>> before the Mar 11 /dev/random commits boots fine, and one just after >>> panics. :( Hopefully Mark can trace down where the data corruption is >>> coming from. I'm willing to test any patches. >> >> Very weird. >> >> Please comment out all the *rijndael* function calls in hash.c and >> see if that fixes anything? (I'm suspecting a stack-smash in the >> rijndael encryption routines). > > I've narrowed it down to the rijndael_blockEncrypt() in yarrow_encrypt(). > Probably it is a buffer overflow of the d_out buffer passed in to that > function. Now I'm off to check all the callers of yarrow_encrypt(). Ok, looking at the calls to yarrow_encrypt(), all the ones that use &genval are probably bogus. genval is only a 64bit integer, but yarrow_encrypt() assumes that it has KEYSIZE bytes to work with. From looking at the Rijndael code, KEYSIZE needs to be at least 16 bytes before it does anything, and checking the headers it is in fact 32 bytes long, or about 24 bytes longer than genval :(. Since genval is static, it's in the data segment, and when you overflow it you end up spewing random data into other variables. At least you can have comfort in knowing that the faulting address was rather random. Patch included below: Index: yarrow.c =================================================================== RCS file: /usr/cvs/src/sys/dev/random/yarrow.c,v retrieving revision 1.33 diff -u -r1.33 yarrow.c --- yarrow.c 2001/03/10 12:51:55 1.33 +++ yarrow.c 2001/03/28 01:04:18 @@ -255,7 +255,7 @@ u_int read_random_real(void *buf, u_int count) { - static u_int64_t genval; + static char genval[KEYSIZE]; static int cur = 0; static int gate = 1; u_int i; @@ -302,8 +302,7 @@ else { retval = cur < count ? cur : count; memcpy(buf, - (char *)&genval + - (sizeof(random_state.counter) - cur), + &genval[(sizeof(random_state.counter) - cur)], retval); cur -= retval; } The second hunk is mostly a style change (I hate pointer arith), you could probably get away with just removing the now unneeded (char *) cast. With this my alpha is back to working, and now I can get back to breaking current with more SMPng commits. This probably causes some kind of data corruption on x86, too. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message