From owner-freebsd-emulation Thu Feb 13 9:10:11 2003 Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEE8A37B405 for ; Thu, 13 Feb 2003 09:10:08 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0BE143F3F for ; Thu, 13 Feb 2003 09:10:07 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id EAA20221; Fri, 14 Feb 2003 04:10:02 +1100 Date: Fri, 14 Feb 2003 04:10:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Milo Hyson Cc: FreeBSD Emulation List Subject: Re: Working on IBM JDK fix In-Reply-To: <3E4BB411.1040302@cyberlifelabs.com> Message-ID: <20030214033116.F4167-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 13 Feb 2003, Milo Hyson wrote: > Bruce Evans wrote: > > ... > > Anyway, applications can easily cause endless errors from this by shooting > > away LDT entries while still using them, and catching SIGBUS without fixing > > up the problem. The SIGBUS handler returns via sigreturn() which triggers > > another SIGBUS at the same %eip if it attempts to reload an invalid segment > > descriptor. > > Might this also explain why 8190 is being returned from modify_ldt()? > Perhaps other registers are being improperly loaded and eax winds up > with this value instead of the intended result code. It might, but I there doesn't seem to be any %eax clobbering, and I think I found the bug... > I did a little more testing and found that the number of times the > trap-26/trap-12 pair shows up in the logs exactly equals the number of > calls made to modify_ldt() where the return value is 8190. Immediately > following the last pair, there's the SIGSEGV in the ktrace and the > looping trap-26's in the logs. I think 8190 is the normal return value but the kernel messes up descriptor 8190 or 8191 due to an off by 1 error. From the current sys_machdep.c: % static int % i386_set_ldt(td, args) % struct thread *td; % char *args; % { % ... % largest_ld = uap->start + uap->num - 1; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ % if (largest_ld >= MAX_LD) % return(EINVAL); `largest_ld' is 1 fewer than the required size of the ldt (in units of descriptors). % % /* allocate user ldt */ % if (!pldt || largest_ld >= pldt->ldt_len) { % struct proc_ldt *new_ldt = user_ldt_alloc(mdp, largest_ld); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But we use `largest_ld' for the size of the table here. Try adding 1 here. In applications, allocate a dummy descriptor at the end. I guess applications mostly worked by doing this accidentally, and the significance of 8190 is that you want to use the very last descriptor (#8191) and there is no way to have a dummy after that. % /* Fill in range */ % savecrit = intr_disable(); % bcopy(descs, % &((union descriptor *)(pldt->ldt_base))[uap->start], % uap->num * sizeof(union descriptor)); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ % td->td_retval[0] = uap->start; % intr_restore(savecrit); We overrun the allocated space by 1 descriptor here, but this descriptor isn't usable even the overrun is not fatal, since it is outside the segment limit. The relevant memory allocations are rounded up to a page boundary, so the overrun is only harmful for unusual ldt sizes like 4096/8 + 1 descriptors. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message