Yes, I've read that padlock design is not elegant at all and true, I don't think so that we will see it redesigned anymore... Though I didn't expect that it might be any difference between i386 and amd64 kernels but after your explanation it makes sense. I have a bit more limited access to nano devices so I just used i386 kernel to all of them when I had a chance. Thank you for the fix.
On Thu, Feb 16, 2017 at 5:04 PM, Thor Lancelot Simon <[email protected]> wrote: > On Thu, Feb 16, 2017 at 01:04:33PM +0200, Andrius V wrote: >> 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. > > I checked in an unconditional version of the fix. > > It's interesting to note (again as pointed out by jak@) 64 bit > kernels would not have had this problem, since they enable SSE > very early in CPU startup. > > The underlying hardware cause for this seems to also be why we > must mess with the coprocessor enables in CR0 before calling > any ACE/RNG instructions -- in Jonathan's testing, even a single > call to xstorerng causes a coprocessor (DNA) fault if the FPU's > off. Unfortunate, since all that monkeying around (interrupt > disable, turn off preemption, whack coproc regs) increases the > cost of getting 8 random bytes by a factor of at least 10. > > The VIA manual suggests they intended to move PadLock out of > the FPU in later designs but I think at this point it is > fairly clear there won't be any of those. > > Thor
