Re: CVS commit: src/sys/arch

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 03/08/2017 à 15:16, Joerg Sonnenberger a écrit :
> On Thu, Aug 03, 2017 at 02:01:04PM +0200, Maxime Villard wrote:
> > Le 03/08/2017 à 13:06, Joerg Sonnenberger a écrit :
> > > On Sat, Jul 01, 2017 at 10:44:43AM +0000, Maxime Villard wrote:
> > > > Module Name:	src
> > > > Committed By:	maxv
> > > > Date:		Sat Jul  1 10:44:43 UTC 2017
> > > >
> > > > Modified Files:
> > > > 	src/sys/arch/amd64/amd64: locore.S
> > > > 	src/sys/arch/i386/i386: locore.S machdep.c trap.c
> > > >
> > > > Log Message:
> > > > Remove the osyscall call gate on i386, and emulate it. There is a one-
> > > > instruction race in it that could panic the kernel.
> > >
> > > Looking back at this -- can't we provide a user-readable/executable page
> > > and replace the call gate with a normal segment pointing to that page?
> >
> > I thought about it, but I could see at least one issue: that page would be
> > allocated dynamically in kern_exec, but the LDT entry is static. We would
> > have to either put the page at a static location - which violates several
> > principles, such as the fact that this area could contain a segment from the
> > binary -, or create per-process LDTs and switch them each time we're doing a
> > context switch - which has several performance drawbacks, along with creating
> > new constraints in the LDT that may violate other ones -.
> >
> > It didn't seem like a good idea, so I ended up simply removing the gate.
> > Chuck came up with another solution, and I just copied it in i386.
>
> I was more thinking in terms of a single page in kernel VA, not in user
> VA. That would side step most of the issues with dynamic LDT or having
> to patch up the default LDT on context switches. That said, the latter
> wouldn't be that difficult either, given that we already do that for the
> GDT.

Mmh, not sure what you mean. If you mean a page that is a kernel page (in the
sense of not having PG_u), then it's a privileged call gate, and we're back
on the first issue (being in kernel mode, with user segment registers, and
interrupts enabled). If you mean a page this a userland page (with PG_u), but
located in the kernel VA range, that's not a good idea: it all of a sudden
makes the map less consistent, and it is more complicated since the upper
levels of the page tree need to have PG_u too.