Re: [PATCH v3 0/2] kvm: x86: hyperv: fix userspace interaction flaws

[Roman Kagan <rkagan@virtuozzo.com>]

On Thu, Jul 13, 2017 at 06:38:29PM +0200, Radim Krčmář wrote:
> 2017-07-13 17:45+0200, Radim Krčmář:
> > 2017-07-13 18:29+0300, Roman Kagan:
> > > On Fri, Jun 23, 2017 at 12:54:25PM +0200, Paolo Bonzini wrote:
> > > > On 22/06/2017 15:51, Roman Kagan wrote:
> > > > Looks good, thanks.
> > > 
> > > Are there still any problems with this series?
> > > I don't see it in kvm queue, so presumably it wasn't accepted...
> > 
> > No, the problem was on my side.  Queing it for the end of this merge
> > window.  Thanks for the ping.
> 
> And took it out after hitting a bug:  we're asking for the VP_INDEX before the
> VCPU is in kvm->vcpus[], but the index is its position in that array.
> I think we can just use kvm->online_vcpus instead of kvm_vcpu_get_idx().
> 
> The error:
> 
> kernel BUG at ./include/linux/kvm_host.h:523!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: kvm_amd(OE) kvm(OE) irqbypass(E) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables sunrpc snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm snd_timer snd sky2 parport_serial ppdev parport_pc joydev parport shpchp sp5100_tco soundcore i2c_piix4 wmi k10temp acpi_cpufreq amdkfd amd_iommu_v2 radeon i2c_algo_bit drm_kms_helper uas serio_raw usb_storage ttm pata_atiixp ata_generic pata_acpi drm pata_jmicron [last unloaded: irqbypass]
> CPU: 0 PID: 8274 Comm: CPU 0/KVM Tainted: G           OE   4.12.0+ #1
> Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080014  03/07/2008
> task: ffff8fe5a4658000 task.stack: ffffb8408211c000
> RIP: 0010:kvm_hv_vcpu_init+0x1bd/0x1c0 [kvm]
> RSP: 0018:ffffb8408211fcf8 EFLAGS: 00010246
> RAX: ffff8fe625800000 RBX: ffff8fe622128000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000080000000 RDI: ffff8fe622128000
> RBP: ffffb8408211fd18 R08: ffff8fe6a6fde960 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffffffffff
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> FS:  00007fd284c55700(0000) GS:ffff8fe6a6e00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005598739115b0 CR3: 00000002201ce000 CR4: 00000000000006f0
> Call Trace:
>  ? kvm_arch_vcpu_init+0x1d8/0x270 [kvm]
>  kvm_vcpu_init+0xcb/0x110 [kvm]
>  svm_create_vcpu+0x4a/0x390 [kvm_amd]
>  kvm_arch_vcpu_create+0x3e/0x60 [kvm]
>  kvm_vm_ioctl+0x1ff/0x8f0 [kvm]
>  ? __lock_acquire+0x31f/0x13b0
>  ? sched_clock+0x9/0x10
>  ? debug_lockdep_rcu_enabled+0x1d/0x30
>  do_vfs_ioctl+0xa6/0x6c0
>  SyS_ioctl+0x79/0x90
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x7fd2934005c7
> RSP: 002b:00007fd284c54808 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007fd284c55700 RCX: 00007fd2934005c7
> RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 000000000000000e
> RBP: 00007ffe60da4210 R08: 000055f38306f5d0 R09: 000055f385dc4000
> R10: 000055f38367ab20 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007ffe60da4230 R14: 00007fd284c559c0 R15: 0000000000000000
> Code: ff 00 00 00 00 48 c7 83 b4 fe ff ff 00 00 00 00 89 83 a4 fe ff ff 41 83 ff 04 0f 85 4a ff ff ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 90 0f 1f 44 00 00 55 48 89 e5 41 54 53 41 89 f4 48 89 fb 
> RIP: kvm_hv_vcpu_init+0x1bd/0x1c0 [kvm] RSP: ffffb8408211fcf8

Hmm, I wonder how I've never hit this...

Thanks for catching,
Roman.