On 26.01.24 г. 15:42 ч., Kirill A. Shutemov wrote:
> 4. Exit to the host/VMM with an error indication after a Confidential
> Computing Guest failed to obtain random input from RDRAND/RDSEED
> instructions after reasonable number of retries. This option allows
> host/VMM to take some correction action for cases when the load on
> RDRAND/RDSEED instructions has been put by another actor, i.e. the
> other guest VM. The exit to host/VMM in such cases can be made
> transparent for the Confidential Computing Guest in the TDX case with
> the assistance of the TDX module component.
But is this really a viable solution in the face of malicious VMM? It
assumes that if the VMM is signaled that randomness has been exhausted
it will try to rectify it, what if such a signal can instead be
repurposed for malicious purposes? Could it perhaps be used as some sort
of a side channel attack ?
>
> On 26.01.24 г. 15:42 ч., Kirill A. Shutemov wrote:
> > 4. Exit to the host/VMM with an error indication after a Confidential
> > Computing Guest failed to obtain random input from RDRAND/RDSEED
> > instructions after reasonable number of retries. This option allows
> > host/VMM to take some correction action for cases when the load on
> > RDRAND/RDSEED instructions has been put by another actor, i.e. the
> > other guest VM. The exit to host/VMM in such cases can be made
> > transparent for the Confidential Computing Guest in the TDX case with
> > the assistance of the TDX module component.
>
> But is this really a viable solution in the face of malicious VMM? It
> assumes that if the VMM is signaled that randomness has been exhausted
> it will try to rectify it, what if such a signal can instead be
> repurposed for malicious purposes? Could it perhaps be used as some sort
> of a side channel attack ?
The idea here is that it is not necessary VMM that is the cause why the
RDRAND/RDSEED fails, so if this is the case, VMM can in theory do smth
about the situation.
We have been thinking about if it can create an additional attack vector,
but were not able to come with one. Do you have any in mind?
Best Regards,
Elena.
On Fri, Jan 26, 2024 at 03:42:12PM +0000, Reshetova, Elena wrote:
> >
> > On 26.01.24 г. 15:42 ч., Kirill A. Shutemov wrote:
> > > 4. Exit to the host/VMM with an error indication after a Confidential
> > > Computing Guest failed to obtain random input from RDRAND/RDSEED
> > > instructions after reasonable number of retries. This option allows
> > > host/VMM to take some correction action for cases when the load on
> > > RDRAND/RDSEED instructions has been put by another actor, i.e. the
> > > other guest VM. The exit to host/VMM in such cases can be made
> > > transparent for the Confidential Computing Guest in the TDX case with
> > > the assistance of the TDX module component.
> >
> > But is this really a viable solution in the face of malicious VMM? It
> > assumes that if the VMM is signaled that randomness has been exhausted
> > it will try to rectify it, what if such a signal can instead be
> > repurposed for malicious purposes? Could it perhaps be used as some sort
> > of a side channel attack ?
>
> The idea here is that it is not necessary VMM that is the cause why the
> RDRAND/RDSEED fails, so if this is the case, VMM can in theory do smth
> about the situation.
>
> We have been thinking about if it can create an additional attack vector,
> but were not able to come with one. Do you have any in mind?
A guest might exit claiming failed RDRAND when in fact no such problem
occurred, as a way to mislead the host admin into taking action against
other guests.
If the CPU performance counters could report RDRAND exhaustion directly,
then the host admin could trust that information and monitor it, but the
host shouldn't rely on the (hostile) guest software to tell it about
exhaustion.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 26.01.24 г. 17:57 ч., Daniel P. Berrangé wrote:
> If the CPU performance counters could report RDRAND exhaustion directly,
> then the host admin could trust that information and monitor it, but the
> host shouldn't rely on the (hostile) guest software to tell it about
I guess it really depends on the POV - from the POV of an encrypted
guest the VMM is hostile so we ideally don't like to divulge more
information than is absolutely necessary.
OTOH, from the POV of the VMM we could say that the guest could be
running anything and so a facility like that could cause some confusion
on the VMM site.
I think it would be very hard to reconcile the 2 views.
> exhaustion.
> On 26.01.24 г. 17:57 ч., Daniel P. Berrangé wrote:
> > If the CPU performance counters could report RDRAND exhaustion directly,
> > then the host admin could trust that information and monitor it, but the
> > host shouldn't rely on the (hostile) guest software to tell it about
>
> I guess it really depends on the POV - from the POV of an encrypted
> guest the VMM is hostile so we ideally don't like to divulge more
> information than is absolutely necessary.
>
> OTOH, from the POV of the VMM we could say that the guest could be
> running anything and so a facility like that could cause some confusion
> on the VMM site.
>
> I think it would be very hard to reconcile the 2 views.
I agree that both views need to be taken into account, and in the confidential
computing threat model nobody has removed the possibility that a CoCo guest
can be malicious. So any action VMM is about to take has to be considered
carefully. We were not prescribing any action here, just asking if VMM would
want to have such a control/option. But since Sean clearly doesn’t find this
approach viable, we will drop the VMM-based option.
Best Regards,
Elena.