Hi, I have tested the fix. lcr4(rcr4() | CR4_OSFXSR); helps indeed and system boots but if statement seems to be not correct, at least on VT-310DP board it ended up in the same error.
On Wed, Feb 15, 2017 at 6:35 PM, Thor Lancelot Simon <t...@panix.com> wrote: > On Wed, Feb 15, 2017 at 10:25:36AM +0200, Andrius V wrote: >> >> Crash looks like this: >> >> cpu_rng: VIA >> fatal privileged instruction fault in supervisor mode >> trap type 0 code 0 eip c0132377 cs 8 eflags 10046 cr2 0 ilevel 8 esp 80050033 >> curlwp 0xc12427e0 pid 0 lid 1 lowest kstack 0xc14d82c0 >> kernel: supervisor trap privileged instruction fault, code=0 >> Stopped in pid 0.1 (system) at netbsd:cpu_rng+0x4a: xstore-rng. > > Jonathan Kollasch found the bug: cpu_rng is called before the FPU > detection code, which would normally enable SSE. SSE must be enabled > the PadLock instructions to actually work, regardless of what the MSR > values say. > > Can you test the following patch, before I commit it? > > > Index: identcpu.c > =================================================================== > RCS file: /cvsroot/src/sys/arch/x86/x86/identcpu.c,v > retrieving revision 1.52 > diff -u -p -r1.52 identcpu.c > --- identcpu.c 2 Feb 2017 08:57:04 -0000 1.52 > +++ identcpu.c 15 Feb 2017 16:32:15 -0000 > @@ -551,7 +551,20 @@ cpu_probe_c3(struct cpu_info *ci) > } > } > > - /* Actually do the enables. */ > + /* > + * Actually do the enables. It's a little gross, > + * but per the PadLock programming guide, "Enabling > + * PadLock", condition 3, we must enable SSE too or > + * else the first use of RNG or ACE instructions > + * will generate a trap. > + * > + * We must do this early because of kernel RNG > + * initialization but it is safe without the full > + * FPU-detect as all these CPUs have SSE. > + */ > + if (cpu_feature[0] & CPUID_FXSR) > + lcr4(rcr4() | CR4_OSFXSR); > + > if (rng_enable) { > msr = rdmsr(MSR_VIA_RNG); > msr |= MSR_VIA_RNG_ENABLE;