On 16.01.2018 15:43, Vitaly Kuznetsov wrote:
> Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:
>
>> On 16/01/2018 14:58, Vitaly Kuznetsov wrote:
>>>> Haven't looked into the details, but we have to watch out for other
>>>> VCPUs trying to modify that vmcs12.
>>>>
>>>> Basically because other VCPUs could try to modify values in vmcs12 while
>>>> we are currently building vmcs02. Nasty races could result in us copying
>>>> stuff (probably unchecked) into vmcs02 and therefore running something
>>>> that was not intended.
>>>>
>>> I don't think we share VMCS among vCPUs, do we?
>>
>> VMCS is just memory, so who knows what a malicious L1 guest will do.
>> But for vmread/vmwrite we can go through hypervisor memory, for
>> enlightened VMCS we cannot.
>>
>
> True; not sure if Hyper-V actually copies the data to some internal
> storage, probably it does. TLFS explicitly forbids making the same
> enlightened VMCS active on several vCPUs simultaneously but again, this
> is just memory...
>
FWIF, on nested s390x we pin the guest provided SIE control block ("SCB"
- s390x VMCS12). As this is just guest memory, another VCPU can write to
that memory.
When building our shadow SCB ("VMCS02"), we directly access the pinned
block, but we basically only copy values and mask them for the critical
parts (execution controls).
However, as I realize, the compiler might fetch values several times, so
we better add READ_ONCE() to these places. Will look into that.
--
Thanks,
David / dhildenb
