Re: [PATCH] x86emul: V{,P}{COMPRESS,EXPAND}* can (wrongly) trigger assertion
Teddy Astie <[email protected]>
| Newsgroups | org.xenproject.lists.xen-devel |
|---|---|
| Message-ID | <1784208936.8631fc262581453bbf619ec5b2062170.19f6b23cedf000edb5@vates.tech> |
Le 16/07/2026 à 12:45, Jan Beulich a écrit :
> AFL has pointed out that the op_bytes-is-not-0 assertion in common SIMD
> handling can trigger for these insns. Indeed when the (relevant part of)
> the controlling mask register is 0, no memory is accessed at all. Leave
> op_bytes unaltered in this case, to engage the short-circuiting in common
> SIMD handling when fault_suppression is true and op_bytes is 0.
>
> While there also correct a related typo in the test harness.
>
> Fixes: 65f82d4ce1ea ("x86emul: support AVX512{F,_VBMI2} compress/expand insns")
> Signed-off-by: Jan Beulich <[email protected]>
> ---
> In a release build, due to op_mask being 0 when n is 0, the short-circuit
> mentioned will prevent any damage.
>
> --- a/tools/tests/x86_emulator/predicates.c
> +++ b/tools/tests/x86_emulator/predicates.c
> @@ -1946,7 +1946,7 @@ static const struct evex {
> { { 0x83 }, 2, T, R, pfx_66, W1, Ln }, /* vpmultishiftqb */
> { { 0x88 }, 2, T, R, pfx_66, Wn, Ln }, /* vpexpandp{s,d} */
> { { 0x89 }, 2, T, R, pfx_66, Wn, Ln }, /* vpexpand{d,q} */
> - { { 0x8a }, 2, T, W, pfx_66, Wn, Ln }, /* vpcompressp{s,d} */
> + { { 0x8a }, 2, T, W, pfx_66, Wn, Ln }, /* vcompressp{s,d} */
> { { 0x8b }, 2, T, W, pfx_66, Wn, Ln }, /* vpcompress{d,q} */
> { { 0x8d }, 2, F, R, pfx_66, Wn, Ln }, /* vperm{b,w} */
> { { 0x8f }, 2, F, R, pfx_66, W0, Ln }, /* vpshufbitqmb */
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -6236,9 +6236,11 @@ x86_emulate(
> ASSERT(op_bytes == n * elem_bytes);
> op_mask &= ~0ULL >> (64 - n);
> n = hweight64(op_mask);
> - op_bytes = n * elem_bytes;
> if ( n )
> + {
> + op_bytes = n * elem_bytes;
> op_mask = ~0ULL >> (64 - n);
> + }
> }
> goto simd_zmm;
>
>
That looks like a bit of a hack in my understanding.
Is there anything specific preventing the common SIMD logic from
accepting op_bytes being 0 ? Otherwise, we risk seeing similar issues
with other instructions (future or current).
OpenPGP_0x660FA9D102CBCFD0.asc
(application/pgp-keys, 2.4 KB)
-----BEGIN PGP PUBLIC KEY BLOCK----- xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7L TBVHV/XOZw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJ T4ny+OGntnJntUoRKRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJA WicutjkkUgd28Bh6HV9EIumHtCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO 8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaTVqMdqul07o72m3eA2mf+LMu9a04FX/d4 wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/EoucejoZ5SH49ksmVAmKOLkt OaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+SPhHar7TPKjFz0G3D PNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89MXfQXZ3q t1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWj moACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNz uyOVCskwfUZPla6Zpd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp 0x0HfuhcYfAYPR46XHTvjaJEv99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuR OxdK8G+YHccJY8PvWSq2K2yiae2KGiAv1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50 wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhPeP3IdpfWc8cyRLXF06Rk46YM YCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcTUwgnYlFRk2FLq0Qe KEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9Egr/Wmu3 MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEM AKiQiZa3yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ 3DbVf+en3/FvdVZg2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTm etSG5/52AjtmPFtlXAk0NmLvfJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0 s3109sJeXT5ImVdphFs9cvyZyBT9t1PbRowv58EgV0zE4hbAeVkULAbxFV5b/ExT jjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKbYu6NCfiHfEyB3Xyg9hfdrRgj MRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ovXoK4jm+Py0FiUGUa A6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/eVtR2Q1w ZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWj moACGwwACgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiV oUiHYN5QwhnbZnsaJDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764Qxy X6rld2f2RcWkDuBHun55ZWXjby8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk /dS0XTOQi2wVUb17sW/+ybCEokdVacZGzOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fu oGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+lOWSvdNHgoEkWR0RXBPQjnGm LKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/OffO485NOTKwGOxyWb0 06cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR8ULR9nX0 LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa =lUIA -----END PGP PUBLIC KEY BLOCK-----
OpenPGP_signature.asc
(application/pgp-signature, 665 B)
-----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmpY3icFAwAAAAAACgkQZg+p0QLLz9CB kwv/aye6WxO31H/AyxXh+ZEcpRD1ze1nBYRX09x+oMx2JxRIoq3YRD7vjht2IYDjfUCvRMhjlEsC ejc7ckwCTTzg4ptFpmqSct11JzBGqC13f7CjZ3andMWDx+6KWSIxrTFxThreHKtgD7hPIEak5uEo BHTKewkzstbkGHfq3uwxuXAXqKJKv1MKKi66T5nwN2phKa8at5eIMEVJpgKtuIgZxJjneWg54pK0 9IqJpW7tO41W/LZG7iLuyEHmC5QAH3qjVDx8CcC3JtbDWwebGL/qvO5S+IFoF+6o/j2otpBmTYtv y23HHe7eg6k/LQUNEH5JoQZ71T1wW7szxXrGYSQ6Em1wMiuiacG3fk2r82dcI5yMJwYvGbLC9J3C HQyK0UrAMiNkUlajg4kTTusypOOAEMyYwdTOxaMQxygxsskXFolg54AhRIxU7iJppeRVXZWtmg+k OlxsXCyj6ncXWfCXfES3lCOLEe5aQ5UncfXmPEhrgSO3Wt6ko92vvR2vAyVe =hBqG -----END PGP SIGNATURE-----