On Tue, Nov 29, 2022 at 07:12:35PM +0000, Mingwei Zhang wrote: > Deprecate BUG() in pte_list_remove() in shadow mmu to avoid crashing a > physical machine. There are several reasons and motivations to do so: > > MMU bug is difficult to discover due to various racing conditions and > corner cases and thus it extremely hard to debug. The situation gets much > worse when it triggers the shutdown of a host. Host machine crash might > eliminates everything including the potential clues for debugging. > > From cloud computing service perspective, BUG() or BUG_ON() is probably no > longer appropriate as the host reliability is top priority. Crashing the > physical machine is almost never a good option as it eliminates innocent > VMs and cause service outage in a larger scope. Even worse, if attacker can > reliably triggers this code by diverting the control flow or corrupting the > memory, then this becomes vm-of-death attack. This is a huge attack vector > to cloud providers, as the death of one single host machine is not the end > of the story. Without manual interferences, a failed cloud job may be > dispatched to other hosts and continue host crashes until all of them are > dead. My only concern with using KVM_BUG() is whether the machine can keep running correctly after this warning has been hit. In other words, are we sure the damage is contained to just this VM? If, for example, the KVM_BUG() was triggered by a use-after-free, then there might be corrupted memory floating around in the machine. What are some instances where we've seen these BUG_ON()s get triggered? For those instances, would it actually be safe to just kill the current VM and keep the rest of the machine running? > > For the above reason, we propose the replacement of BUG() in > pte_list_remove() with KVM_BUG() to crash just the VM itself. How did you test this series?
