> From: Jan Beulich <jbeul...@suse.com> > Sent: Wednesday, February 1, 2023 5:30 PM > > On 01.02.2023 06:07, Tian, Kevin wrote: > >> From: Xenia Ragiadakou <burzalod...@gmail.com> > >> Sent: Tuesday, January 24, 2023 8:42 PM > >> > >> The variable untrusted_msi indicates whether the system is vulnerable to > >> CVE-2011-1898 due to the absence of interrupt remapping support. > >> Although AMD iommus with interrupt remapping disabled are also > affected, > >> this case is not handled yet. Given that the issue is not VT-d specific, > >> and to accommodate future use of the flag for covering also the AMD > iommu > >> case, move the definition of the flag out of the VT-d specific code to the > >> common x86 iommu code. > >> > >> Also, since the current implementation assumes that only PV guests are > >> prone > >> to this attack, take the opportunity to define untrusted_msi only when PV > is > >> enabled. > >> > > > > I'm fine with this change given no functional change. > > > > But I'm curious about the statement here that the current code only > > applies to PV guest. I didn't see such statement in original mail [1] > > and in concept a HVM guest with passthrough device can also do such > > attack w/o interrupt remapping. > > > > Any more context? > > Isn't this simply because we don't allow HVM to have devices assigned > without intremap? (I'm not sure, but even for PV allowing this may > have been limited to the xend tool stack.) >
OK, this is what I'm seeking. Reviewed-by: Kevin Tian <kevin.t...@intel.com>
