On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov <gleb@xxxxxxxxxx> wrote:
> On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
>> On 09/19/2014 10:15 AM, Gleb Natapov wrote:
>> > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
>> >> On 09/19/2014 09:53 AM, Gleb Natapov wrote:
>> >>> On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
>> >>>> On 09/19/2014 09:37 AM, Gleb Natapov wrote:
>> >>>>>
>> >>>>> Linux detects what hypervior it runs on very early
>> >>>>
>> >>>> Not anywhere close to early enough. We're talking for uses like kASLR.
>> >>>>
>> >>> Still to early to do:
>> >>>
>> >>> h = cpuid(HYPERVIOR_SIGNATURE)
>> >>> if (h == KVMKVMKVM) {
>> >>> if (cpuid(kvm_features) & kvm_rnd)
>> >>> rdmsr(kvm_rnd)
>> >>> else (h == HyperV) {
>> >>> if (cpuid(hv_features) & hv_rnd)
>> >>> rdmsr(hv_rnd)
>> >>> else (h == XenXenXen) {
>> >>> if (cpuid(xen_features) & xen_rnd)
>> >>> rdmsr(xen_rnd)
>> >>> }
>> >>>
>> >>
>> >> If we need to do chase loops, especially not so...
>> >>
>> > What loops exactly? As a non native English speaker I fail to understand
>> > if your answer is "yes" or "no" ;)
>> >
>>
>> The above isn't actually the full algorithm used.
>>
> What part of actually algorithm cannot be implemented? Loop that searches
> for KVM leaf in case KVM pretend to be HyperV (is this what you called
> "chase loops"?)? First of all there is no need to implement it, if KVM
> pretends to be HyperV use HyperV's way to obtain RNG, but what is the
> problem with the loop?
>
It can be implemented, and I've done it. But it's a mess. Almost the
very first thing we do in boot (even before decompressing the kernel)
will be to scan a bunch of cpuid leaves looking for a hypervisor with
an rng source that we can use for kASLR. And we'll have to update
that code and make it bigger every time another hypervisor adds
exactly the same feature.
And then we have another copy of almost exactly the same code in the
normal post-boot part of the kernel.
We can certainly do this, but I'd much rather solve the problem once
and let all of the hypervisors and guests opt in and immediately be
compatible with each other.
> I "forgot" VMware because I do not see VMware people to be CCed. They may
> be even less excited about them being told _how_ this feature need to be
> implemented (e.g implement HyperV leafs for the feature detection). I
> do not want to and cannot speak for VMware, but my guess is that for
> them it would be much easier to add an else clause for VMware in above
> "if" then to coordinate with all hypervisor developers about MSR/cpuid
> details. And since this is security feature implementing it for Linux
> is in their best interest.
Do you know any of them who should be cc'd?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
