UBUNTU: SAUCE: x86/KVM: Clean up host's steal time structure
CVE-2019-3016
Now that we are mapping kvm_steal_time from the guest directly we
don't need keep a copy of it in kvm_vcpu_arch.st. The same is true
for the stime field.
This is part of CVE-2019-3016.
Signed-off-by: Boris Ostrovsky <email address hidden>
Reviewed-by: Joao Martins <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>
UBUNTU: SAUCE: x86/KVM: Make sure KVM_VCPU_FLUSH_TLB flag is not missed
CVE-2019-3016
There is a potential race in record_steal_time() between setting
host-local vcpu->arch.st.steal.preempted to zero (i.e. clearing
KVM_VCPU_PREEMPTED) and propagating this value to the guest with
kvm_write_guest_cached(). Between those two events the guest may
still see KVM_VCPU_PREEMPTED in its copy of kvm_steal_time, set
KVM_VCPU_FLUSH_TLB and assume that hypervisor will do the right
thing. Which it won't.
Instad of copying, we should map kvm_steal_time and that will
guarantee atomicity of accesses to @preempted.
This is part of CVE-2019-3016.
Signed-off-by: Boris Ostrovsky <email address hidden>
Reviewed-by: Joao Martins <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>
kvm_vcpu_(un)map operates on gfns from any current address space.
In certain cases we want to make sure we are not mapping SMRAM
and for that we can use kvm_(un)map_gfn() that we are introducing
in this patch.
This is part of CVE-2019-3016.
Signed-off-by: Paolo Bonzini <email address hidden>
Signed-off-by: Boris Ostrovsky <email address hidden>
Reviewed-by: Joao Martins <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>
When device-mapper adapted for multi-queue functionality, they
also re-organized the way the make-request function was set.
Before, this happened when the device-mapper logical device was
created. Now it is done once the mapping table gets loaded the
first time (this also decides whether the block device is request
or bio based).
However in generic_make_request(), the request function gets used
without further checks and this happens if one tries to mount such
a partially set up device.
This can easily be reproduced with the following steps:
- dmsetup create -n test
- mount /dev/dm-<#> /mnt
This maybe is something which also should be fixed up in device-
mapper. But given there is already a check for an unset queue
pointer and potentially there could be other drivers which do or
might do the same, it sounds like a good move to add another check
to generic_make_request_checks() and to bail out if the request
function has not been set, yet.
Fixes: ff36ab34583a ("dm: remove request-based logic from make_request_fn wrapper")
Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Andrea Righi <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>