linux-kernel - Re: [PATCH] kvm: x86: svm: remove SVM_EXIT_READ

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:	Mon, 16 Mar 2015 11:16:05 -0500
From:	Joel Schopp <joel.schopp@....com>
To:	Radim Krčmář <rkrcmar@...hat.com>
CC:	Gleb Natapov <gleb@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>, <kvm@...r.kernel.org>,
	Joerg Roedel <joro@...tes.org>, Borislav Petkov <bp@...en8.de>,
	<linux-kernel@...r.kernel.org>, David Kaplan <david.kaplan@....com>
Subject: Re: [PATCH] kvm: x86: svm: remove SVM_EXIT_READ_CR* intercepts



On 03/12/2015 04:20 PM, Radim Krčmář wrote:
> 2015-03-12 15:17-0500, Joel Schopp:
>> There isn't really a valid reason for kvm to intercept cr* reads
>> on svm hardware.  The current kvm code just ends up returning
>> the register
> There is no need to intercept CR* if the value that the guest should see
> is equal to what we set there, but that is not always the case:
> - CR0 might differ from what the guest should see because of lazy fpu
Based on our previous conversations I understand why we have to trap the
write to the CR0 ts bit for lazy fpu, but don't understand why that
should affect a read.  I'll take another look at the code to see what
I'm missing.  You are probably correct in which case I'll modify the
patch to only turn off the read intercepts when lazy fpu isn't active.

> - CR3 isn't intercepted with nested paging and it should differ
>   otherwise
> - CR4 contains PAE bit when run without nested paging
>
> CR2 and CR8 already aren't intercepted, so it looks like only CR0 and
> CR4 could use some optimizations.
I'll send out a v2 with these less aggressive optimizations.
--
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/