On 11/16/24 15:10, Borislav Petkov wrote:
On Sat, Nov 16, 2024 at 03:02:47PM +0300, Maksim Davydov wrote:
Yes, BTC_NO and AMD_IBPB_RET are used by guests while choosing mitigations.
How?
Basically what the current code does to do retbleed or IBPB on entry? Where
latter means the HV allows writes to MSR_IA32_PRED_CMD...?
Not sure If I understood your question correctly, but I meant these two
examples:
* BTC_NO. For instance, we want to create Zen2 (family 17h) guest on
host with Zen4 (family 19h) processor. If guest doesn't have
X86_FEATURE_BTC_NO, blacklist will be used to determine whether CPU
model is vulnerable to retbleed or not. 17h family is in the blacklist.
So, the guest will use "untrained return thunk" or another retbleed
mitigation. But we can expose to the guest that host processor (family
19h) isn't vulnerable to rebleed and improve guest performance without
any security risks
* AMD_IBPB_RET. On AMD we can pass through MSR_IA32_PRED_CMD. So, the
guest can use IBPB on entry to mitigate SRSO (instead of the default
mitigation). In this case I don't see any problems, because KVM allows
writes to MSR_IA32_PRED_CMD. But AMD_IBPB_RET is used to determine the
appropriate stub in end of entry_ibpb. Without exposing AMD_IBPB_RET,
the guest will use stronger mitigation.
I don't have access to Zen4 host now, but it seems that both of these
cases can have an impact on performance. I can try to measure this
impact later if needed.
--
Best regards,
Maksim Davydov
