Re: [RFC PATCH v2 02/10] drm/vino: add the clean-room HDCP 2.2 AKE/LC/SKE handshake

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The HDCP OUT message builder `body()` omits a mandatory 2-byte padding at the start of the message body, misaligning the header fields and payload by 2 bytes.
--

commit ff0736a0543094c7762c8587ebbe6bbde5a3fe43
Author: Mike Lothian <mike@fireburn.co.uk>

drm/vino: add the clean-room HDCP 2.2 AKE/LC/SKE handshake

This commit introduces a clean-room implementation of the HDCP 2.2 handshake
(AKE/LC/SKE) for the vino driver. It includes cryptographic adapters, protocol
message builders, key derivation routines, and captured plaintext
control-plane skeletons. The implementation builds and parses wire frames
strictly verified against the reference daemon traffic.

> diff --git a/drivers/gpu/drm/vino/ake.rs b/drivers/gpu/drm/vino/ake.rs
> new file mode 100644
> index 0000000000000..38919624cb2f3
> --- /dev/null
> +++ b/drivers/gpu/drm/vino/ake.rs
[ ... ]
> +/// Allocate a body_len-byte zeroed body with the sec 5.1 header filled in
> +/// (sub_size, the 0x0010 marker, hdcp_seq, the 0x30 marker and msg_id).
> +/// The caller writes the payload into body[28..].
> +fn body(body_len: usize, sub_size: u16, hdcp_seq: u32, msg_id: u8) -> Result<KVec<u8>> {
> +    let mut b = KVec::from_elem(0u8, body_len, GFP_KERNEL)?;
> +    b[0..2].copy_from_slice(&sub_size.to_le_bytes());
> +    b[2..4].copy_from_slice(&0x0010u16.to_le_bytes());
> +    b[4..8].copy_from_slice(&hdcp_seq.to_le_bytes());
> +    b[22..26].copy_from_slice(&0x0000_0030u32.to_le_bytes());
> +    b[27] = msg_id;

[Severity: High]
Does this message builder omit a mandatory 2-byte padding at the start of the
payload?

Comparing this against the golden capture (CAP_PLAIN_1080P) in golden.rs, the
48-byte body starts with a 2-byte zero padding at offsets 16-17 (right after
the 16-byte transport header), placing the sub_size at offsets 18-19 (body
offset 2).

By writing sub_size at b[0..2], hdcp_seq at b[4..8], the marker at b[22..26],
and msg_id at b[27], the entire layout appears to be shifted left by 2 bytes
compared to the expected hardware offsets.

Will this misalignment cause the dock to reject the HDCP handshake because
the fields and cryptographic payload are not where the hardware expects them?

> +    Ok(b)
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703030217.2886-1-mike@fireburn.co.uk?part=2