It turns out that a bug (since forever) in Xen causes XSAVE records to have
non-architectural behaviour on xsave-capable hardware, when a PV guest has not
touched the state.
In such a case, the data record returned from Xen is 2*uint64_t, both claiming
the (illegitimate) state of %xcr0 and %xcr0_accum being 0.
Adjust the bound in handle_x86_pv_vcpu_blob() to cope with this.
Fixes: 2a62c22715b "libxc/restore: Fix data auditing in handle_x86_pv_vcpu_blob()"
Reported-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wl@xen.org>
(cherry picked from commit
0729830cc425a8ff27a3137e87b93768ae3c853c)
(cherry picked from commit
d2aecd86c4481291b260869c47cf0a9a02321564)
(cherry picked from commit
e43fc14ec58329813af876ed3b30899a04d65a08)
(cherry picked from commit
7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab)
break;
case REC_TYPE_X86_PV_VCPU_XSAVE:
- if ( blobsz < 128 )
+ if ( blobsz < 16 )
{
ERROR("%s record too short: min %zu, got %u",
- rec_name, sizeof(*vhdr) + 128, rec->length);
+ rec_name, sizeof(*vhdr) + 16, rec->length);
goto out;
}
break;