linux-kernel - Re: [PATCH stable v5.4+ 1/3] x86/kvm: Teardown PV features on boot CPU as well

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: <42392f1d-4547-9c66-f429-f81f55e86574@canonical.com>
Date:   Thu, 20 May 2021 13:17:54 -0400
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Paolo Bonzini <pbonzini@...hat.com>, stable@...r.kernel.org,
        x86@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        Andrea Righi <andrea.righi@...onical.com>
Subject: Re: [PATCH stable v5.4+ 1/3] x86/kvm: Teardown PV features on boot
 CPU as well

On 20/05/2021 12:47, Paolo Bonzini wrote:
> On 20/05/21 14:56, Krzysztof Kozlowski wrote:
>> From: Vitaly Kuznetsov <vkuznets@...hat.com>
>>
>> commit 8b79feffeca28c5459458fe78676b081e87c93a4 upstream.
>>
>> Various PV features (Async PF, PV EOI, steal time) work through memory
>> shared with hypervisor and when we restore from hibernation we must
>> properly teardown all these features to make sure hypervisor doesn't
>> write to stale locations after we jump to the previously hibernated kernel
>> (which can try to place anything there). For secondary CPUs the job is
>> already done by kvm_cpu_down_prepare(), register syscore ops to do
>> the same for boot CPU.
>>
>> Krzysztof:
>> This fixes memory corruption visible after second resume from
>> hibernation:
> 
> Hi, you should include a cover letter detailing the differences between 
> the original patches and the backport.
> 
> (I'll review it anyway, but it would have helped).

My bad, I actually was not aware that backport differs that much. I can
describe in v2.

The patch context looks quite a different and now I see
kvm_guest_cpu_offline() ends up within CONFIG_SMP for unclear reasons.
Let me try to fix it in v2.


Best regards,
Krzysztof