Small Ivy features: FSGSBASE and SMEP.

[Konstantin Belousov]

On Sun, Sep 09, 2012 at 11:29:05PM +0300, Konstantin Belousov wrote:
> On Sun, Sep 09, 2012 at 02:02:55PM +0300, Konstantin Belousov wrote:
> > On Sun, Sep 09, 2012 at 08:42:37AM +0200, Michael Fuckner wrote:
> > > Hi all,
> > > 
> > > I changed your patch slightly to apply to specialreh.h on STABLE
> > > 
> > > root at c64:/root # diff smep.1.patch.bak smep.1.patch
> > > 80c80
> > > < diff --git a/sys/x86/include/specialreg.h b/sys/x86/include/specialreg.h
> > > ---
> > > > diff --git a/sys/amd64/include/specialreg.h 
> > > b/sys/amd64/include/specialreg.h
> > > 82,83c82,83
> > > < --- a/sys/x86/include/specialreg.h
> > > < +++ b/sys/x86/include/specialreg.h
> > > ---
> > > > --- a/sys/amd64/include/specialreg.h
> > > > +++ b/sys/amd64/include/specialreg.h
> > > 
> > > I got a new kernel, but it is stuck immediately (kerneltrap 9 with 
> > > interrupts disabled), system doesn't boot on E3-1230 V2 on Supermicro 
> > > X9SCM-IIF
> > > 
> > > Anything else I could check?
> > I need the backtrace and the whole kernel messages.
> At least, there was a typo in the definition of CR4_FSGSBASE.
> I still need verbose dmesg and panic messages, if any, with the
> http://people.freebsd.org/~kib/misc/smep.2.patch 
> version of the patch.
> 

With a help from Andrey, who has access to the hardware supporting SMEP,
I fixed the issue with double-fault on SMEP enable. The issue was due
to loader(8) making a handoff to the kernel with 1GB identity mapping
which has the PG_U bit set. As a result, after enabling the CR4.SMEP,
the #pf was generated immediately. But since the handler, if any, is
also mapped with PG_U, double-fault happen and machine was reset.

Updated patch, also fixing other minor problems with the features display,
is at http://people.freebsd.org/~kib/misc/smep.3.patch .

Please test.
> > 
> > > 
> > > Regards,
> > >  Michael!
> > > 
> > > 
> > > On 09/08/2012 08:10 PM, Konstantin Belousov wrote:
> > > >Please find at
> > > >http://people.freebsd.org/~kib/misc/smep.1.patch
> > > >the patch which should enable the FSGSBASE and SMEP features
> > > >supposedly present in the IvyBridge CPUs.
> > > >
> > > >FSGSBASE are four new instructions available in the 64bit mode only.
> > > >They allow to access bases for %fs and %gs without touching MSRs.
> > > >This makes it possible to both read and write bases in the user mode,
> > > >or in ring 0 with lower overhead.
> > > >
> > > >At the moment, WRFSBASE/WRGSBASE instructions should work, but are
> > > >useless since any interrupt or context switch overrides bases with the
> > > >values set by the arch syscall. Still, RDFSBASE/RDGSBASE might be useful
> > > >for some code and I see no reason not to enable them.
> > > >
> > > >SMEP is the nice feature of the processor which makes it trap if ring
> > > >0 tries to execute an instruction from usermode-accessible page. It is
> > > >another mitigation for things like calling user-controllable function
> > > >pointer in kernel, as well as a protection for NULL function pointer
> > > >dereference.
> > > >
> > > >I am sure that we never execute anything in kernel from user page, but
> > > >I did not tested the patch since I have no Ivy machine.
> > > >
> > > >I need your reports about boot on Ivy with patch applied. Please include
> > > >the lines from verbose dmesg with CPU Features. In particular, the
> > > >'Standard Extended Features' report should appear in output.
> > > >
> > > >Thanks.
> > > >
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20121030/7294cd24/attachment.sig>