On 19/05/2022 07:59, Jan Beulich wrote: > On 19.05.2022 02:10, Andrew Cooper wrote: >> On 17/05/2022 14:21, Roger Pau Monne wrote: >>> Under certain conditions guests can get the CPU stuck in an infinite >>> loop without the possibility of an interrupt window to occur. >> instruction boundary. >> >> It's trivial to create an infinite loop without an interrupt window :) >> >> Also, I'd probably phrase that as an unbounded loop, because not all >> problem cases are truly infinite. >> >>> This >>> was the case with the scenarios described in XSA-156. >> Case in point, both of these can be broken by something else (another >> vCPU, or coherent DMA write) editing the IDT and e.g. making the #AC/#DB >> vectors not present, which will yield #NP instead. > "Can be broken" as in "the loop can be forced to be exited"? If so, how > would a remote CPU / agent become aware of the situation, and know what > the cause is (and hence know which IDT entry to clobber)? After all it's > guest state, which we wouldn't want to alter for no reason. Nor should > we put a guest in a state where #DF might eventually result.
Well quite... "Can be broken" does not mean that this approach is a viable security defence. It does highlight that the loop only continues while there is no perturbation to the memory accesses involved. ~Andrew
