linux-kernel - Re: [PATCH] kvm: arm/arm64 : fix vm's hanging at startup time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <01746207-c9bb-dc91-58d7-a66c0d971f88@arm.com>
Date:   Mon, 19 Nov 2018 12:49:34 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     peng.hao2@....com.cn
Cc:     Mark Rutland <mark.rutland@....com>, julien.thierry@....com,
        andre.przywara@....com, linux-kernel@...r.kernel.org,
        kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org,
        ard.bieshseuvel@...aro.org, leif.lindholm@...aro.org
Subject: Re: [PATCH] kvm: arm/arm64 : fix vm's hanging at startup time

On 19/11/2018 09:10, Mark Rutland wrote:
> On Sat, Nov 17, 2018 at 10:58:37AM +0800, peng.hao2@....com.cn wrote:
>>> On 16/11/18 00:23, peng.hao2@....com.cn wrote:
>>>>> Hi,
>>>>>> When virtual machine starts, hang up.
>>>>>
>>>>> I take it you mean the *guest* hangs? Because it doesn't get a timer
>>>>> interrupt?
>>>>>
>>>>>> The kernel version of guest
>>>>>> is 4.16. Host support vgic_v3.
>>>>>
>>>>> Your host kernel is something recent, I guess?
>>>>>
>>>>>> It was mainly due to the incorrect vgic_irq's(intid=27) group value
>>>>>> during injection interruption. when kvm_vgic_vcpu_init is called,
>>>>>> dist is not initialized at this time. Unable to get vgic V3 or V2
>>>>>> correctly, so group is not set.
>>>>>
>>>>> Mmh, that shouldn't happen with (v)GICv3. Do you use QEMU (which
>>>>> version?) or some other userland tool?
>>>>>
>>>>
>>>> QEMU emulator version 3.0.50 .
>>>>
>>>>>> group is setted to 1 when vgic_mmio_write_group is invoked at some
>>>>>> time.
>>>>>> when irq->group=0 (intid=27), No ICH_LR_GROUP flag was set and
>>>>>> interrupt injection failed.
>>>>>>
>>>>>> Signed-off-by: Peng Hao <peng.hao2@....com.cn>
>>>>>> ---
>>>>>>   virt/kvm/arm/vgic/vgic-v3.c | 2 +-
>>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
>>>>>> index 9c0dd23..d101000 100644
>>>>>> --- a/virt/kvm/arm/vgic/vgic-v3.c
>>>>>> +++ b/virt/kvm/arm/vgic/vgic-v3.c
>>>>>> @@ -198,7 +198,7 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu,
>>>>>> struct vgic_irq *irq, int lr) if (vgic_irq_is_mapped_level(irq) &&
>>>>>> (val & ICH_LR_PENDING_BIT)) irq->line_level = false;
>>>>>>
>>>>>> -    if (irq->group)
>>>>>> +    if (model == KVM_DEV_TYPE_ARM_VGIC_V3)
>>>>>
>>>>> This is not the right fix, not only because it basically reverts the
>>>>> GICv3 part of 87322099052 (KVM: arm/arm64: vgic: Signal IRQs using
>>>>> their configured group).
>>>>>
>>>>> Can you try to work out why kvm_vgic_vcpu_init() is apparently called
>>>>> before dist->vgic_model is set, also what value it has?
>>>>> If I understand the code correctly, that shouldn't happen for a GICv3.
>>>>>
>>>> Even if the value of  group is correctly assigned in kvm_vgic_vcpu_init, the group is then written 0 through vgic_mmio_write_group.
>>>>   If the interrupt comes at this time, the interrupt injection fails.
>>>
>>> Does that mean that the guest is configuring its interrupts as Group0?
>>> That sounds wrong, Linux should configure all it's interrupts as
>>> non-secure group1.
>>
>> no, I think that uefi dose this, not linux.
>> 1. kvm_vgic_vcpu_init 
>> 2. vgic_create 
>> 3. kvm_vgic_dist_init 
>> 4.vgic_mmio_write_group: uefi as guest, write group=0
>> 5.vgic_mmio_write_group: linux as guest, write group=1
> 
> Is this the same issue fixed by EDK2 commit:
> 
> 66127011a544b90e ("ArmPkg/ArmGicDxe ARM: fix encoding for GICv3 interrupt acknowledge")
> 
> ... where EDK2 would try to use IAR0 rather than IAR1?
> 
> The commit messages notes this lead to a boot-time hang.

I managed to trigger an issue with a really old EFI implementation that
doesn't configure its interrupts as Group1, and yet tries to ACK its
interrupts using the Group1 accessor. Guess what? It is not going to work.

Commit c7fefb690661f2e38afcb8200bd318ecf38ab961 in the edk2 tree seems
to be the fix (I only assume it does, I haven't actually checked). A
recent build, as found in Debian Buster, works perfectly (tested with
both QEMU v2.12 and tip of tree).

Now, I really don't get what you're saying about Linux not getting
interrupts. How do you get to booting Linux if EFI is not making any
forward progress? Are you trying them independently?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...