From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] kvm: x86: do not leak guest xcr0 into host interrupt handlers Date: Thu, 7 Apr 2016 11:08:18 +0200 Message-ID: <57062382.6070005@redhat.com> References: <1459365887-146735-1-git-send-email-dmatlack@google.com> <5703A175.4000005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: kvm list , "linux-kernel@vger.kernel.org" , Andy Lutomirski , stable@vger.kernel.org To: David Matlack Return-path: In-Reply-To: Sender: stable-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 05/04/2016 17:56, David Matlack wrote: > On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote: >> > ... >> >> While running my acceptance tests, in one case I got one CPU whose xcr0 >> had leaked into the host. This showed up as a SIGILL in strncasecmp's >> AVX code, and a simple program confirmed it: >> >> $ cat xgetbv.c >> #include >> int main(void) >> { >> unsigned xcr0_h, xcr0_l; >> asm("xgetbv" : "=d"(xcr0_h), "=a"(xcr0_l) : "c"(0)); >> printf("%08x:%08x\n", xcr0_h, xcr0_l); >> } >> $ gcc xgetbv.c -O2 >> $ for i in `seq 0 55`; do echo $i `taskset -c $i ./a.out`; done|grep -v 007 >> 19 00000000:00000003 >> >> I'm going to rerun the tests without this patch, as it seems the most >> likely culprit, and leave it out of the pull request if they pass. > > Agreed this is a very likely culprit. I think I see one way the > guest's xcr0 can leak into the host. That's cancel_injection, right? If it's just about moving the load call below, I can do that. Hmm, I will even test that today. :) Paolo