From owner-cvs-src@FreeBSD.ORG Tue Apr 12 17:08:16 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6335116A4D1 for ; Tue, 12 Apr 2005 17:08:16 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AC4543D39 for ; Tue, 12 Apr 2005 17:08:15 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18255 invoked from network); 12 Apr 2005 17:08:15 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 12 Apr 2005 17:08:14 -0000 Received: from [131.106.57.68] (p178.n-lapop01.stsn.com [12.129.240.178]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3CH871F022095; Tue, 12 Apr 2005 13:08:08 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Bill Paul Date: Tue, 12 Apr 2005 11:24:46 -0400 User-Agent: KMail/1.8 References: <20050412011519.E879716A4CF@hub.freebsd.org> In-Reply-To: <20050412011519.E879716A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504121124.48590.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.2 required=4.2 tests=ALL_TRUSTED,SUBJ_HAS_SPACES autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: julian@elischer.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/compat/ndis hal_var.h kern_ndis.c kern_windrv.c ndis_var.h ntoskrnl_var.h pe_var.h subr_hal.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 17:08:16 -0000 On Monday 11 April 2005 09:15 pm, Bill Paul wrote: > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > > On Monday 11 April 2005 02:54 pm, Julian Elischer wrote: > > > Bill Paul wrote: > > > >wpaul 2005-04-11 02:02:35 UTC > > > > > > > > > > > > The twist has to do with the fact that Microsoft supports structured > > > > exception handling in kernel mode. On the i386 arch, exception > > > > handling is implemented by hanging an exception registration list off > > > > the Thread Environment Block (TEB), and the TEB is accessed via the > > > > %fs register. The problem is, we use %fs as a pointer to the pcpu > > > > stucture, which means any driver that tries to write through %fs:0 > > > > will overwrite the curthread pointer and make a serious mess of > > > > things. > > > > > > > > To get around this, Project Evil now creates a special entry in > > > > the GDT on each processor. When we call into Windows code, a context > > > > switch routine will fix up %fs so it points to our new descriptor, > > > > which in turn points to a fake TEB. When the Windows code returns, > > > > or calls out to an external routine, we swap %fs back again. > > > > Currently, Project Evil makes use of GDT slot 7, which is all 0s by > > > > default. I fully expect someone to jump up and say I can't do that, > > > > but I couldn't find any code that makes use of this entry anywhere. > > > > Sadly, this was the only method I could come up with that worked on > > > > both UP and SMP. (Modifying the LDT works on UP, but becomes > > > > incredibly complicated on SMP.) If necessary, the context switching > > > > stuff can be yanked out while preserving the convention calling > > > > wrappers. > > > > > > Maybe we could emulate $soft and use %fs as a thread pointer instead > > > and have pcpu > > > pointed to via that :-) > > > > I think NDIS drivers want %fs to point to a Windows-specific structure > > rather than a 'struct thread' so I don't think that would buy us anything > > except for even more memory indirects when we do a pcpu lookup. > > John is correct. %fs points to the Windows TEB. I haven't dug up the > exact structure definition for the TEB yet, but I know that the first > DWORD in the TEB structure is a pointer to the exception handler > list. So when Windows drivers do, say, mov %eax,%fs:0 and think > they're writing to the exception list pointer in struct TEB, they're > actually writing to curthread in struct pcpu. > > Now, we could have dodged the bullet by modifying struct pcpu slightly > so that the first thing in is a dummy unused pointer, which would shift > curthread down out of the way. Then Windows drivers could scribble on > %fs:0 all they want and there'd be no problems. But I'm not about to > redefine a core OS structure just to make Windows drivers happy. > > It also occured to me that what I could have done was save the > curthread pointer somewhere during the UNIX-to-Windows context > switch, let the drivers trash it, then restore it when switching > from Windows-to-UNIX again. But if an interrupt occured while the CPU > happened to be in 'Windows' context, there would be no way to restore > the curthread pointer before entering interrupt context (whereas %fs > is saved/restored when entering interrupt context). Also, going ahead and faking up a TEB means that it's easier to handle the case of drivers trying to use or modify other TEB fields later if you run into it. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org