linux-kernel - Re: [PATCH] KVM: x86: expose MSR_TSC

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CA+0KQ4NEPcLqueaN4rKcpr-1u5t7Y=G-AGBcemY+hAChFHnJRw@mail.gmail.com>
Date:	Fri, 13 Nov 2015 09:49:27 -0800
From:	Peter Hornyack <peterhornyack@...gle.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	kvm list <kvm@...r.kernel.org>, linux-kernel@...r.kernel.org,
	Radim Krcmar <rkrcmar@...hat.com>, stable@...r.kernel.org,
	Feng Min <fmin@...gle.com>,
	Eric Northup <digitaleric@...gle.com>
Subject: Re: [PATCH] KVM: x86: expose MSR_TSC_AUX to userspace

On Fri, Nov 13, 2015 at 1:42 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
>> Paolo, under what circumstances (which versions of Windows? Anything
>> special running in the guest?) has this failure happened? I'd like to repro
>> this, I'm not sure if we've observed it before.
>
> We saw it with migration under Windows 10, nothing special running in the
> guest.  It's very hard to reproduce, we've only seen it once but the BSOD
> parameters provided surprisingly good evidence:

Great, thanks for that information and for the patch. I'll let you
know if I successfully reproduce the issue here.

> ----------------------------------
> CRITICAL_STRUCTURE_CORRUPTION (109)
> This bugcheck is generated when the kernel detects that critical kernel code or
> data have been corrupted. There are generally three causes for a corruption:
> 1) A driver has inadvertently or deliberately modified critical kernel code
>  or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
> 2) A developer attempted to set a normal kernel breakpoint using a kernel
>  debugger that was not attached when the system was booted. Normal breakpoints,
>  "bp", can only be set if the debugger is attached at boot time. Hardware
>  breakpoints, "ba", can be set at any time.
> 3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
> Arguments:
> Arg1: a3a01f58a88e3638, Reserved
> Arg2: b3b72bdefb0f076f, Reserved
> Arg3: 00000001c0000103, Failure type dependent information
> Arg4: 0000000000000007, Type of corrupted region, can be
>         ...
>         7   : Critical MSR modification
> ----------------------------------
>
> Argument 1 and 2 might be related to the old and new value (perhaps some
> kind of hash).
>
> Argument 3 is not documented either, but the low 32 bits look a lot like
> the MSR_TSC_AUX index. :)
>
> Paolo

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