linux-kernel - Re: [PATCH] KVM/x86: Do not clear SIPI while in SMM

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c7091688-8af5-4e70-b2d7-6d0a7134dbbe@redhat.com>
Date: Tue, 16 Apr 2024 22:53:22 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Boris Ostrovsky <boris.ostrovsky@...cle.com>, kvm@...r.kernel.org
Cc: seanjc@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM/x86: Do not clear SIPI while in SMM

On 4/16/24 22:47, Boris Ostrovsky wrote:
> When a processor is running in SMM and receives INIT message the interrupt
> is left pending until SMM is exited. On the other hand, SIPI, which
> typically follows INIT, is discarded. This presents a problem since sender
> has no way of knowing that its SIPI has been dropped, which results in
> processor failing to come up.
> 
> Keeping the SIPI pending avoids this scenario.

This is incorrect - it's yet another ugly legacy facet of x86, but we 
have to live with it.  SIPI is discarded because the code is supposed to 
retry it if needed ("INIT-SIPI-SIPI").

The sender should set a flag as early as possible in the SIPI code so 
that it's clear that it was not received; and an extra SIPI is not a 
problem, it will be ignored anyway and will not cause trouble if there's 
a race.

What is the reproducer for this?

Paolo