linux-kernel - Re: [Qemu-devel] x86, nops settings result in kernel crash

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Aug 2012 16:51:46 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Tomas Racek <tracek@...hat.com>
Cc:	qemu-devel@...gnu.org, "H. Peter Anvin" <hpa@...ux.intel.com>,
	Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...ux.intel.com>,
	kvm-devel <kvm@...r.kernel.org>, Avi Kivity <avi@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [Qemu-devel] x86, nops settings result in kernel crash

Alan Cox <alan@...rguk.ukuu.org.uk> writes:

> On Thu, 16 Aug 2012 14:45:15 -0400 (EDT)
> Tomas Racek <tracek@...hat.com> wrote:
>
>> ----- Original Message -----
>> > On Thu, Aug 16, 2012 at 09:35:12AM -0400, Tomas Racek wrote:
>> > > Hi,
>> > > 
>> > > I am writing a file system test which I execute in qemu with kernel
>> > > compiled from latest git sources and running it causes this error:
>> > > 
>> > > https://bugzilla.kernel.org/show_bug.cgi?id=45971
>> > > 
>> > > It works with v3.5, so I ran git bisect which pointed me to:
>> > > 
>> > > d6250a3f12edb3a86db9598ffeca3de8b4a219e9 x86, nops: Missing break
>> > > resulting in incorrect selection on Intel
>> > > 
>> > > To be quite honest, I don't understand this stuff much but I tried
>> > > to do some debugging and I figured out (I hope) that the crash is
>> > > caused by setting ideal_nops to p6_nops (k8_nops was used before
>> > > the break statement was added).
>> > 
>> > Maybe I overlooked it or maybe it was implied but did you try
>> > reverting
>> > the patch and rerunning your test? Does it work ok then?
>> > 
>> 
>> Yes, if I remove the break statement (introduced by this commit), it works fine.
>
> What version of qemu is this - do we have qemu bug here I wonder.

>From the cpuinfo, it's 0.15.1.  That's old but not ancient.

I took a brief look at the kernel code here.  The default invocation of
qemu presents an idealistic CPU with a very minimum feature bit set
exposed.  No processor has ever existed with this feature set.

We do this in order to maintain compatibility when migration from Intel
to AMD but also for legacy reasons.

>From the report, using '-cpu host' solves the problem.  '-cpu host'
exposes most of the host CPUID to the guest.

That said, QEMU really doesn't do anything differently depending on what
feature bits are exposed to the guest.  So my guess is that the odd
combination of CPUID bits that are exposed to the guest is confusing the
kernel.

Can you post dmesg from the host kernel?  Perhaps there's instruction
emulation failing in the host KVM?  That would manifest in strange
behavior in the guest.

Regards,

Anthony Liguori

>
> Alan
--
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/