RMM should be designed to avoid GICv3 interrupt injection

[n1ptune]

When entering a realm, the RMM will copy the GICv3_LRs from rec_enter. Since this data is controlled by the NS, unauthorized data injection or deletion may occur, posing security risks. Therefore, I suggest saving the GICv3_LRs locally in the RMM instead of exposing them to the normal world hypervisor. If needed, I can submit a pull request to address this issue.

[raghuncstate]

This is aligned with the RMM spec and Cca threat model. Interrupt registers can be used to cause interrupt injection and realm sw is expected to assume they are untrusted too. Not too different than registers being provided untrusted value via RHI host calls for example.
Was there a more concrete example attack you had in mind specifically with gic lr?

[n1ptune]

When a device is assigned to a Realm, the interrupts generated by the device are routed to the Realm through the GIC. I am unsure whether these interrupts are exposed to the Non-Secure (NS) Host. Detecting interrupt injection within the Realm VM is quite cumbersome. If the GIC's functionality is controlled within the RMM, this issue could be resolved more simply.

[soby-mathew]

Hi @n1ptune ,

The RMM specification states that "The Host is able to inject virtual interrupts using the GIC virtual CPU interface." and "Management of Non-secure physical interrupts is performed by the Host, via the GIC Interrupt Routing Infrastructure (IRI)."

With GICv3/v4 architecture, Realm assigned device interrupts are non-secure interrupts and hence these are managed by the NS Host. While the RMM provides confidentiality and integrity protections, the RMM specification implies a threat model in which the Interrupt injection must be considered a potential attack vector. The Realm software is expected to defend against maliciously timed interrupts. RMM does not block or filter interrupts at the architectural level, nor does it guarantee that interrupts won’t be misused by the Host.

Realm VMs must not rely on interrupts for performing its tasks. And it should be hardened against maliciously timed interrupt.
It is cumbersome, but there is no alternative for this. I think this shortcoming will resolved with GICv5 architecture but I haven't studied GICv5 in depth to comment further.