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? 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. >Received on Sun Sep 09 2012 - 04:42:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC