On 6/19/23 13:23, Reshetova, Elena wrote: >> And BTW, doesn't it mean that interrupts also need to be hardened in the >> guest (if we don't want the complexity of interrupt controllers in the >> trusted hypervisor)? At least sensitive ones like IPIs, but I guess we >> should also consider interrupt-based timings attacks, which could use >> any type of interrupt. (I have no idea how to harden either of the two >> cases, but I'm no expert.) > > We have been thinking about it a bit at least when it comes to our > TDX case. Two main issues were identified: interrupts contributing > to the state of Linux PRNG [1] and potential implications of missing > interrupts for reliable panic and other kernel use cases [2]. > > [1] https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html#randomness-inside-tdx-guest > [2] https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html#reliable-panic > > For the first one, in addition to simply enforce usage of RDSEED > for TDX guests, we still want to do a proper evaluation of security > of Linux PRNG under our threat model. The second one is > harder to reliably asses imo, but so far we were not able to find any > concrete attack vectors. But it would be good if people who > have expertise in this, could take a look on the assessment we did. > The logic was to go over all kernel core callers of various > smp_call_function*, on_each_cpu* and check the implications > if such an IPI is never delivered. Thanks. I also had in mind for example [1]. [1] https://people.cs.kuleuven.be/~jo.vanbulck/ccs18.pdf
