linux-kernel - Re: [PATCH] KVM: SVM: fix trashing of 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160708125553.GG3808@pd.tnic>
Date:	Fri, 8 Jul 2016 14:55:54 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Eduardo Habkost <ehabkost@...hat.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	stable@...r.kernel.org, Yazen Ghannam <yazen.ghannam@....com>,
	Brijesh Singh <brijesh.singh@....com>,
	Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX

On Fri, Jul 08, 2016 at 07:15:39AM -0400, Paolo Bonzini wrote:
> It does sometimes happen that there is no state.  For example it could be
> an MSR that we are already getting in and out of KVM.

Right.

> However, it is way more common that you have to add support for
> reading/writing the MSR in KVM as well, and then teach QEMU's
> target-i386/kvm.c about it as well.
>
> It's hard to say without knowing exactly what the feature is about...
> Is there an architecture manual out there that documents it?

Maybe section 2.16 here:
http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf

In any case, here are two bit definitions:

1	SUCCOR: Software uncorrectable error containment and recovery
	capability. Value: 1. 1=The processor supports software containment of
	uncorrectable errors through context synchronizing data poisoning
	and deferred error interrupts; see 2.16.1.10 [Deferred Errors and Data
	Poisoning]; MSR MSRC000_0410 [Machine Check Deferred Error Configuration
	(CU_DEFER_ERR)] exists.

0	McaOverflowRecov: MCA overflow recovery support. Value: 1. 1=MCA
	overflow conditions (MCi_STATUS[Overflow]=1) are not fatal; software
	may safely ignore such conditions. 0=MCA overflow conditions require
	software to shut down the system. See 2.16.1.6 [Handling Machine Check
	Exceptions].

So AFAICT the McaOverflowRecov thing should be the easiest by making
sure MCi_STATUS[Overflow]=1 is set properly when MCEs happen.

The SUCCOR thing needs data poisoning and deferred error interrupts and
that's a lot more involved than the overflow handling. And we'll need to
touch a lot more places. But it doesn't hurt to start looking at them at
least.

Bottom line is, the more RAS features we could test with qemu/kvm the
better because generating those error conditions on a real system is
very very hard and sometimes even impossible. Especially if you try to
inject an error but then the BIOS facility which does that is b0rked
because vendor forgot it. Crap like that.

I'll do some looking into all that when I get free moments, who knows,
we might get something going...

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.