Re: CVS commit: src/sys/arch/amd64/amd64

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

Le 23/06/2019 à 09:50, maya%netbsd.org@localhost a écrit :
> On Sun, Jun 23, 2019 at 09:17:26AM +0200, Maxime Villard wrote:
> > Le 22/06/2019 à 22:29, maya%netbsd.org@localhost a écrit :
> > > On Fri, Dec 01, 2017 at 09:22:45PM +0000, Maxime Villard wrote:
> > > > Module Name:	src
> > > > Committed By:	maxv
> > > > Date:		Fri Dec  1 21:22:45 UTC 2017
> > > >
> > > > Modified Files:
> > > > 	src/sys/arch/amd64/amd64: machdep.c process_machdep.c
> > > >
> > > > Log Message:
> > > > Don't even bother with the trap frame, and force the default values.
> > >
> > >
> > > What's the rationale?
> > > Not getting the correct values for registers in getmcontext is
> > > unexpected and weird.
> >
> > FYI, in 64bit mode, x86 does not enforce segmentation. You can set whatever
> > base/limit in the segregs, it doesn't get applied.
> >
> > Moreover, certain instructions like 'syscall' force certain segregs to default
> > values, regardless of what userland had set.
> >
> > Also, if you look at the commit before, you can see I had found an info leak
> > caused by the fact that we were fetching the segregs without masking them
> > properly.
> >
> > So, given that (1) these segregs have no functional change, (2) some are forced
> > to default values anyway, and (3) the way we were fetching them had already
> > proven to be buggy, I just dropped the thing and set the default values.
> >
> > This is expected and normal, likely prevents future bugs, and also simplifies
> > the understanding of USER_LDT.
>
> I don't know what things meant for segmentation, but at least FS got
> repurposed to be the thread pointer in the ABI programs linking with C
> use (and programs not calling C code go wild with their register usage).

I drew you the big picture, but basically yes there are certain exceptions, and
FS/GS are one. With FS/GS, the base does get enforced.

%fs is a "selector", which selects an entry in the GDT or LDT. When you set %fs
to a value, the CPU will copy the base/limit/attributes of the pointed GDT/LDT
entry into the FS.base/FS.limit/FS... registers (a set of hidden registers not
accessible directly).

In 64bit however, the FS.base register *can* be accessed directly, via the
MSR_FSBASE msr. What we do in NetBSD x86_64 is: set %fs to zero (so that the
CPU resets the FS.* registers), and then use MSR_FSBASE to write the actual
base we want into FS.base, see locore.S::.Llwp_64bit.

Here, again, changing tf_fs does not have an actual impact on the FS.base
address. So my patch did not cause a functional change, it just simplified
things.