From owner-freebsd-current Tue Oct 5 9:14:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 9D2F81560A for ; Tue, 5 Oct 1999 09:14:31 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id MAA20723; Tue, 5 Oct 1999 12:12:48 -0400 (EDT) (envelope-from luoqi) Date: Tue, 5 Oct 1999 12:12:48 -0400 (EDT) From: Luoqi Chen Message-Id: <199910051612.MAA20723@lor.watermarkgroup.com> To: luoqi@watermarkgroup.com, marcel@scc.nl Subject: Re: CVSup segfaults identified/solved [PATCH] Cc: freebsd-current@FreeBSD.ORG, jdp@polstra.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Luoqi Chen wrote: > > > > o restoring %gs is now handled in the proper sigreturn. > > > > Restoration of %gs should not be in the kernel because it comes from > > user application and maybe invalid, if you restore it inside the kernel > > it could be fatal to the whole system, and on the other hand just a core > > dump if done in the trampoline code which is still in user mode. > > Hmmm... What if the application passes a (possibly handcrafted) > sigcontext to an explicit call to sigreturn. %gs should be restored in > that case too, right? > > Isn't it therefore better to have %gs in the trapframe? > > -- > Marcel Moolenaar mailto:marcel@scc.nl > SCC Internetworking & Databases http://www.scc.nl/ > The FreeBSD project mailto:marcel@FreeBSD.org > The only place sigreturn is called explicitly is to enter VM86 mode, and in that case, %gs is restored inside kernel as part of vm86 trapframe. In fact, you may choose to restore %gs in the kernel, but you have to be prepared to take a fault on the load_gs operation and to recover from the fault properly. The reason why %gs is not in the trapframe is that trapframe is used at all entrances to the kernel (syscall/trap/intr), if %gs is included, then we need to save and restore %gs for each syscall/trap/intr, that's about 40 clock cycles wasted each time. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message