Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [High] The memory layout of `union hv_device_domain_id` is inverted compared 
to the expected Hyper-V ABI, resulting in corrupted device domain IDs being 
passed to the hypervisor.
--

--- Patch [5]: [PATCH V4 5/9] mshv: Import data structs around device passthru 
from hyperv headers ---
commit 02ed2cd292e85f0b6e754b6a29df473f95394315
Author: Mukesh R <[email protected]>

mshv: Import data structs around device passthru from hyperv headers

This commit copies and imports definitions and declarations from Hyper-V
public headers. These additions are related to creating domains in the
hypervisor and attaching devices to them.

> diff --git a/include/hyperv/hvhdk_mini.h b/include/hyperv/hvhdk_mini.h
> index b4cb2fa26e9bc..90497635c3cbd 100644
> --- a/include/hyperv/hvhdk_mini.h
> +++ b/include/hyperv/hvhdk_mini.h

[ ... ]

> +/* 3 domain types: stage 1, stage 2, and SOC */
> +#define HV_DEVICE_DOMAIN_TYPE_S2  0 /* HV_DEVICE_DOMAIN_ID_TYPE_S2 */
> +#define HV_DEVICE_DOMAIN_TYPE_S1  1 /* HV_DEVICE_DOMAIN_ID_TYPE_S1 */
> +#define HV_DEVICE_DOMAIN_TYPE_SOC 2 /* HV_DEVICE_DOMAIN_ID_TYPE_SOC */
> +
> +/* ID for stage 2 default domain and NULL domain */
> +#define HV_DEVICE_DOMAIN_ID_S2_DEFAULT 0
> +#define HV_DEVICE_DOMAIN_ID_S2_NULL    0xFFFFFFFFULL
> +
> +union hv_device_domain_id {
> +     u64 as_uint64;
> +     struct {
> +             u32 type : 4;
> +             u32 reserved : 28;
> +             u32 id;
> +     };
> +} __packed;

[Severity: High]
Is the memory layout of union hv_device_domain_id inverted compared to the
expected Hyper-V ABI?

The macro HV_DEVICE_DOMAIN_ID_S2_NULL is defined as 0xFFFFFFFFULL, which
places 0xFFFFFFFF in the lower 32 bits and 0 in the upper 32 bits. Given
that Stage 2 (S2) domains have a type of 0, this macro implies that the id
should be in the lower 32 bits and the type should be in the upper 32 bits.

However, union hv_device_domain_id defines type as the first bitfield
(occupying the lower 32 bits) and id as the second (occupying the upper 32
bits).

Under this layout, casting 0xFFFFFFFFULL evaluates to type = 15 and id = 0,
instead of the expected type = 0 and id = 0xFFFFFFFF. Could this cause
malformed domain IDs to be sent to the hypervisor?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=5

Reply via email to