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]

Date:	Thu, 7 Jul 2016 19:04:42 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Eduardo Habkost <ehabkost@...hat.com>
Cc:	Paolo Bonzini <pbonzini@...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>
Subject: Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX

On Thu, Jul 07, 2016 at 01:27:55PM -0300, Eduardo Habkost wrote:
> You mean KVM kernel patches?

No, other ones. Here's one example:

https://lkml.kernel.org/r/1467633035-32080-2-git-send-email-Yazen.Ghannam@amd.com

> I assume the features require additional KVM code to support them
> in guests. In that case, why wouldn't the kernel return them in
> GET_SUPPORTED_CPUID? Then you won't need filter=off.

Yeah, so in most cases they will need additional KVM code to enable
them. More often than not, this is not always at the top of the TODO
list of people so ...

That's why I did the quick thing of smoke-testing them by enabling only
CPUID bits and the filter=off thing.

Would it be nicer to see them actually implemented in qemu/kvm?
Definitely.

> About filter=off: not sure. Do we really have valid use cases to
> enable a feature even if the kernel reports it as unsupported in
> GET_SUPPORTED_CPUID?

Yeah, as said above, the filter=off thing was a dirty hack just to stop
x86_cpu_filter_features() from checking whether the host supports them
or not.

> Do those features introduce additional state that need migration
> support? If they do, you need to add them to
> feature_word_info[FEAT_8000_0007_EBX].unmigratable_flags until
> migration support is implemented.

I'm afraid you'd need to explain migration support to me: is the
question whether migrating the guest to an Intel platform and whether
the features would still work?

Because those three above are AMD-only and they won't work on an Intel
platform.

And if so, I'm guessing they should always remain unmigratable.

Which is not a problem as there are Intel features which are not present
on AMD so...

Thanks!

-- 
Regards/Gruss,
    Boris.

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