On Fri, 2025-07-11 at 07:19 -0700, Sean Christopherson wrote:
> --
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index f4d4fd5cc6e8..9c2997665762 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -181,6 +181,8 @@ static int init_kvm_tdx_caps(const struct tdx_sys_info_td_conf *td_conf,
> {
> int i;
>
> + memset(caps->reserved, 0, sizeof(caps->reserved));
> +
> caps->supported_attrs = tdx_get_supported_attrs(td_conf);
> if (!caps->supported_attrs)
> return -EIO;
> --
I started to try to help by chipping in a log for this, but I couldn't justify
it very well. struct kvm_tdx_capabilities gets copied from userspace before
being populated So a userspace that knows to look for something in the reserved
area could know to zero it. If they left their own data in the reserved area,
and then relied on that data to remain the same, and then we started setting a
new field in it I guess it could disturb it. But that is strange, and I'm not
sure it really reduces much risk. Anyway here is the attempt to justify it.
KVM: TDX: Zero reserved reserved area in struct kvm_tdx_capabilities
Zero the reserved area in struct kvm_tdx_capabilities so that fields added in
the reserved area won't disturb any userspace that previously had garbage there.
struct kvm_tdx_capabilities holds information about the combined support of KVM
and the TDX module. For future growth, there is an area of the struct marked as
reserved. This way fields can be added into that space without increasing the
size of the struct.
However, currently the reserved area is not zeroed, meaning any data that
userspace left in the reserved area would be clobbered by a future field written
in the reserved area. So zero the reserved area to reduce the risk that
userspace might try to rely on some data there.
