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 <[email protected]> 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/[email protected]?part=2
