lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 9 Mar 2014 19:50:11 +0100 From: Borislav Petkov <bp@...en8.de> To: Paolo Bonzini <pbonzini@...hat.com> Cc: "H. Peter Anvin" <hpa@...ux.intel.com>, Dave Jones <davej@...hat.com>, Fengguang Wu <fengguang.wu@...el.com>, Ingo Molnar <mingo@...nel.org>, Yinghai Lu <yhlu.kernel@...il.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [qemu64,+smep,+smap] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/cpu/amd.c:220 init_amd() On Sun, Mar 09, 2014 at 07:07:02PM +0100, Paolo Bonzini wrote: > tl;dr: do not use qemu64, especially in system emulation mode. In > user mode it should work, user mode programs are less susceptible to > bogus family/member/stepping. When using dynamic translation in > system emulation mode, use Haswell,+smap or Opteron_G3,+smep,+smap. > When using KVM, use whatever CPU model you're running on (or a least > common denominator if doing migration). > > qemu64's family/member/stepping makes no sense at all. It is a > really odd combination that means "enable all features that the QEMU > dynamic translator supported at some time where people cared about > -cpu qemu64". So it has SVM and at the same time it misses > SMEP/SMAP. It also lacks some instruction set extensions such as > BMI and ADX that QEMU does implement (I don't know if the kernel has > any hand-optimized assembly that uses them). Nope, not yet. It would definitely be worth to check to see whether they bring anything performance-wise and if so, alternative-lize them in :-) > *** If the above already worsened your opinion of virt people, skip > *** the next three paragraphs. I don't want to give you a bad day. qemu+kvm can never worsen my opinion - it is my favourite virt solution! :-) > On KVM we always make the vendor the same as the host because of the > sysenter/syscall mess in 32-bit mode (AMD supports one and Intel > supports the other). Oh yeah, there was that. > But even if you're using Intel the family/member/stepping remains AMD! Right. > We really should give a loud warning if qemu64 is used with KVM. It > makes no sense with KVM, even less than it does with dynamic > translation. Right, yes, so Fengguang did switch to the Haswell model now so the issue at hand is addressed. > On TCG it does make some sense that vendor is AMD, because QEMU can > emulate SVM. So perhaps we could change the family/member/stepping > to e.g. an Opteron G3 (the last AMD chip without xsave/xrstor), I'm looking at target-i386/cpu.c and Opteron_G3 is family 15 decimal. However, the last AMD Opteron which *didn't* have XSAVE (CPUID Fn0000_0001_ECX[26]) is family 0x10 AFAIR, i.e. 16 decimal. I dunno though, whether correcting that would cause other grief. It might be worth a try to start cleaning up that mess though. :-P > but then with KVM you would have family=15 on Intel and I don't want > to go there. Perhaps we could give a loud warning with qemu64+KVM, and > then do the above. Yeah, if this warning saves people some time when having to look into it, it might be worth it. > You're not adding the bit to TCG_EXT2_FEATURES, so it's masked out. Ah, there was that too. But filter_features_for_kvm() clears it too because that bit is reserved in CPUID on newer AMD and Intel hosts. > The patch has also some backwards-compatibility gunk missing, and > we're in hard-freeze now, but if you remind me at the end of April > (I'm on vacation until April 23) I'll try to fix all this mess for > QEMU 2.1. That's some serious vacation - kinda like month and a half. :-) But I'll probably forget so put it on your TODO list :-) I'm willing to help out reviewing, should the need arise. > Well, it's "64" for a reason. LM in qemu64 is perhaps the only > thing that makes sense. :) Hahaa. Thanks for the info! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists