Messages in this thread | | | Date | Tue, 31 Dec 2013 14:21:06 -0500 | From | Konrad Rzeszutek Wilk <> | Subject | Re: Sanitize CPU-state when switching from virtual-8086 mode to other task |
| |
On Tue, Dec 31, 2013 at 10:42:47AM -0800, H. Peter Anvin wrote: > On 12/30/2013 07:52 AM, halfdog wrote: > >> > >> Still in VirtualBox? > > > > Yes, again: after comparing the results from initrd on real hardware > > with Vbox, I'm getting to understand the timing problem involved and why > > timing in VBox is different: The test program usually OOPSes when > > touching FPU multiple times, otherwise, when terminated before second > > FPU-interacation, it OOPSes on next invocation, stumbling over invalid > > CPU state from prior invocation. With improved code, I can rather > > reliably bring CPU into that state, so that next process invoked and > > touching FPU/MMX-state is OOPSed. Currently searching SUID-binaries and > > running UID=0 daemons, that might show interesting reaction on that > > event, but only on DOS level yet, e.g. after running V2 test program > > once and then connecting via SSH, this currently kills the ssh daemon > > nicely. > > > > It seems that machine lockup occurs when e.g. switch to idle task > > happens at exactly the right moment, which I currently cannot trigger on > > real hardware, but still working on that. > > > > I'm still wondering if this is a VirtualBox-specific problem or if it is > something that *could* occur on hardware, or in other virtualization > environments (KVM, Xen HVM, Hy-perV, VMware etc.)
So, I am wondering if this is related to " x86/fpu: CR0.TS should be set before trap into PV guest's #NM exception handle" which does have a similar pattern - you do enough of the task switches and the FPU is screwed.
See http://mid.gmane.org/1383720072-6242-1-git-send-email-gaoyang.zyh@taobao.com
(I thought there was a thread about this on LKML too but I can't find it). > > -hpa > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
| |