On Tue, Jan 03, 2012 at 04:50:58PM +0100, Christian Borntraeger wrote:
> struct kvm_sync_rw_regs {
> + __u64 gprs[16]; /* general purpose registers */
> + s390_fp_regs fpregs;
> + unsigned int acrs[16];
So, if I got this right, userspace is allowed to map this shared read/write
with the kernel? If that's the case then...
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 0badc9f..a7b7ae0 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -269,9 +269,9 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> {
> save_fp_regs(&vcpu->arch.host_fpregs);
> save_access_regs(vcpu->arch.host_acrs);
> - vcpu->arch.guest_fpregs.fpc &= FPC_VALID_MASK;
> - restore_fp_regs(&vcpu->arch.guest_fpregs);
> - restore_access_regs(vcpu->arch.guest_acrs);
> + vcpu->run->sync_rw.fpregs.fpc &= FPC_VALID_MASK;
> + restore_fp_regs(&vcpu->run->sync_rw.fpregs);
...this is broken, since userspace can update the floating point control
register contents after the kernel has masked out the offending bits but
before the register is actually loaded.
Which in turn could cause a kernel crash, hm?
--
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
