From owner-freebsd-current Wed May 27 16:16:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29711 for freebsd-current-outgoing; Wed, 27 May 1998 16:16:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from hotmail.com (f47.hotmail.com [207.82.250.58]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA29586 for ; Wed, 27 May 1998 16:15:05 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 17329 invoked by uid 0); 27 May 1998 23:14:22 -0000 Message-ID: <19980527231422.17328.qmail@hotmail.com> Received: from 166.55.240.72 by www.hotmail.com with HTTP; Wed, 27 May 1998 16:14:21 PDT X-Originating-IP: [166.55.240.72] From: "Brian Feldman" To: jlemon@americantv.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: current instabilities Content-Type: text/plain Date: Wed, 27 May 1998 16:14:21 PDT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's the entire scenario: FreeBSD 3.0-VERYVERYCURRENT doscmd -b booted on a 10m dos image drive ZSNES 0.4 for DOS X11 running I ran doscmd -b, then tried to run ZSNES, and it locked the system. Is this really X's fault then? If so, would I only have to have the computer in X to have this lock it up? Seeing as all activity stopped on the computer, not just consoles locking, I tend to believe that either the kernel froze itself, or doscmd somehow let the clock irq get turned off (hope not ;). Perhaps you should try out ZSnes? Brian Feldman >From jlemon@americantv.com Wed May 27 14:12:35 1998 >Received: from right.PCS (right.PCS [148.105.10.31]) > by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA27018 > for ; Wed, 27 May 1998 16:01:52 -0500 (CDT) >Received: (from jlemon@localhost) > by right.PCS (8.6.13/8.6.4) id QAA08873; > Wed, 27 May 1998 16:01:21 -0500 >Message-ID: <19980527160121.09643@right.PCS> >Date: Wed, 27 May 1998 16:01:21 -0500 >From: Jonathan Lemon >To: Brian Feldman >Subject: Re: current instabilities >References: <19980527191549.17187.qmail@hotmail.com> >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >X-Mailer: Mutt 0.61.1 >In-Reply-To: <19980527191549.17187.qmail@hotmail.com>; from Brian Feldman on May 05, 1998 at 12:15:42PM -0800 > >On May 05, 1998 at 12:15:42PM -0800, Brian Feldman wrote: >> Well, yes, I am pretty sure it was VM86. Doscmd doesn't use user_ldt, >> I'm pretty sure, does it? I was using doscmd, not Wine, and making world >> at the same time (-j4, no softupdates, no biggie) and wasn't expecting >> for it to lock up my computer. What I was trying to run was ZSnes for >> DOS, a SNES emulator, and immediately the system froze. I suppose yes, >> this could be an attempt to access video hardware, but is it really a >> good idea to allow any access of that (and other) memory regions to a >> user, if it can be so easily exploited? You should be able to get a copy >> of zsnes at http://zsnes.home.ml.org to try it out, but you seem to >> already be on top of the problem. BTW, I didn't try and see if it only >> locked up the console and keyboard because I don't have a serial console >> to break to, just a monitor. And if you wouldn't mind to take the time >> to explain the working of vm86/user_ldt to me, I'd appreciate it; like, >> what's a "local descriptor table", and is the danger in vm86 caused by >> direct memory access, through /dev/{k}mem, or something else? Maybe if I >> understood the concept I might be able to help make it safer than it is >> now, but I'd need to understand the concepts first... > >doscmd executes everything in a "vm86 penalty box", which is a special >mode of operation that causes the Intel chip to act like an 8088. > >The biggest difficulty is in making sure that none of the privileged >instructions leak out and affect the machine; DOS programs like to turn >off interrupts, which would cause a lockup of the system, since all >keyboard activity is interrupt driven. This is achieved by a kernel >module that emulates the interrupt handling, and tells doscmd that >the interrupts are on or off, but should never actually turn interrupts >off. > >IIRC, doscmd does not have direct access to any hardware, video or >otherwise. The hooks are in there, but are not enabled by default. > >If it managed to lock up the system, it would be because there is a bug >somewhere in the kernel handling of interrupts. > >Were you running doscmd under X or on a raw terminal? >-- >Jonathan > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message