Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Oct 1999 12:12:48 -0400 (EDT)
From:      Luoqi Chen <luoqi@watermarkgroup.com>
To:        luoqi@watermarkgroup.com, marcel@scc.nl
Cc:        freebsd-current@FreeBSD.ORG, jdp@polstra.com
Subject:   Re: CVSup segfaults identified/solved [PATCH]
Message-ID:  <199910051612.MAA20723@lor.watermarkgroup.com>

next in thread | raw e-mail | index | archive | help
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910051612.MAA20723>