Re: [Xen-devel] NMI SERR interrupts in dom0

[GÃbor PÃK <pek@xxxxxxxxx>]

On 2013.02.08. 17:55, Jan Beulich wrote:
>>>> On 08.02.13 at 15:51, GÃbor PÃK<pek@xxxxxxxxx> wrote:
>> [+] At the same time, PCI SERR interrupts refer to hardware errors that
>> is generated by my passthrough NIC directly, so I expect that these
>> interrupts are physical (e.g., MSIs) so they should go directly either
>> to the BSP or one of the APs. However, Interrupt remapping is in place
>> which should check the origin of such interrupts and should remap the
>> interrupts by using the BDF id of the device. Thus, the real interrupt
>> is generated by the Interrupt Remapping hardware unit which is still a
>> physical one. Am I right?
> 
> No, NMIs don't go through the remapping hardware, they get
> delivered directly to the CPU. Which makes sense, because they
> point out a problem in the system as a whole, regardless of
> whether a device having caused them is assigned to a guest

I faced this NMI issue while looking at the security of Xen, however, it
raises security concerns in my mind. If an NMI does not go through the
Interrupt Remapping engine (which makes sense due to its non-maskable
nature), then a "malicious" NMI could give rise to either a DoS attack
or code execution problems with ring1 privileges. In the former case the
reason could be the uncleared EOI register for the specific CPU after
NMI generation, while in the latter case the code injection might be
difficult, but the concern is still valid I think.

Furthermore, an attacker can generate such NMIs via MSIs from untrusted
HVM domains by means of a PT device in xAPIC mode easily. x2APIC mode
(in together with Interrupt Remapping) could give mitigation against
such malicious DMA writes by accessing LAPIC registers via MSRs and
enforcing the Remappable MSI format. However, if an attacker can create
NMI conditions in x2apic mode as well, then the Remappable Format does
not make sense at all (as the NMI is not handled by the remapping
engine). So what I feel that there is no real hardware/software solution
for this issue...
> 
> Note that because of the possibility of multiple devices raising
> such an NMI, I think it is also not possible for Xen to actually know
> which device(s) caused the NMI, and hence it has no way to
> associate it with a particular guest, even if it wanted to.

Can this explain why my NMI does not appear in the /proc/interrupts in
dom0 while the handler is executed with ring1 privileges?

Thank you!
-gabor

> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel