Update dsAVDTypes.h for HDCP key buffer size improvement

[aminaseyyad]

No description provided.

[Copilot]

Pull request overview

This PR updates the public AVD types header to increase the maximum allowed HDCP key buffer size, enabling callers to provide larger HDCP key payloads via existing APIs.

Changes:

• Increase HDCP_KEY_MAX_SIZE from 4 KiB to 10 KiB in include/dsAVDTypes.h.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[srinivasgtl]

What is the basis for this 10KB increase? If you are only carrying a standalone HDCP 2.x key, 4KB is technically sufficient. However, if your RDKE implementation follows the RDKV pattern of bundling DRM assets into one binary:

Align with RDKV (50KB): This is the safest approach for long-term compatibility with future DRM updates (e.g., larger Widevine certificates or PlayReady bundles).

Consistency: Using 10KB may solve your immediate truncation issue but could fail if a future Netflix or Widevine update increases the total bundle size beyond that limit.

We need to understand technically what the better size will be to cater to all our future needs. Had this been discussed with Architects?

[aminaseyyad]

Thanks for the inputs @srinivasgtl
We analyzed the current DRM binary sizes and found that the largest DRM binary currently in use is approximately 7216 bytes (including HDCP 2.2 TX, Netflix, PlayReady, Widevine, and ESN). Based on this:

• The existing 4 KB limit is insufficient and causes truncation.
• Increasing to 10 KB will be sufficient (~40%) for current deployments.

Regarding alignment with RDKV (50 KB):

• In RDKE, MAX_SERIALIZED_BUF is part of an IARM struct where the buffer is allocated as a fixed-size array on the stack:
      char buffer[MAX_SERIALIZED_BUF];
• Increasing this to 50 KB may introduce stack overflow risks in constrained environments.

Therefore, 10 KB is chosen as a balanced value which fixes the immediate issue, covers current and near-term DRM bundle sizes and avoids stack-related risks.

[srinivasgtl]

Here are some suggestions from @outdooruseonly (Arch team)
I would suggest the #define is left unchanged. It will effectively become a minimum size. Document in header.

And

Add a new function getMaxHdcpKeySize().

A platform with a TESTED larger key size can advertise it, and an updated MW implementation can read the size.

Older MW with no changes will continue to use the old definition. No risk.

When the HAL implementation is updated to use the new header. It will be a platform capability and should be tested with the new increased size or advertise the old minimum.

[SUGANTHAP]

Thanks @srinivasgtl.
Can you share more details on below queries to have new function,
Q1: If we will have new function as getMaxHdcpKeySize(), then shall i know, how will it be handled in below struct in https://github.com/rdkcentral/devicesettings/blob/1d252893efd2445c308bc0306a90076a3293a6b8/rpc/include/dsRpc.h#L720

_typedef struct dsEnableHDCPParam
{
intptr_t handle;
bool contentProtect;
char hdcpKey[HDCP_KEY_MAX_SIZE];
size_t keySize;
dsError_t rpcResult;
} dsEnableHDCPParam_t;

Q2: How should we advertise the platform using a larger key size?

[srinivasgtl]

Problem
HDCP_KEY_MAX_SIZE is currently hardcoded to 4KB in the common HAL header. Since this is shared across platforms, it does not account for the fact that different platforms have different HDCP key size requirements — ranging from less than 4KB to up to 10KB. This results in either wasted memory on constrained platforms or an insufficient buffer on platforms that require more.

Proposed Fix

1. Update dsEnableHDCPParam_t to use a dynamic pointer
   Replace the fixed-size char hdcpKey[HDCP_KEY_MAX_SIZE] with a pointer, where the buffer is allocated by the caller based on the platform's reported capability:

ctypedef struct dsEnableHDCPParam {
intptr_t handle;
bool contentProtect;
char hdcpKey; / caller allocates based on dsGetMaxHdcpKeySize() /
size_t keySize; / actual key size in bytes */
dsError_t rpcResult;
} dsEnableHDCPParam_t;

2. Introduce dsGetMaxHdcpKeySize() to expose platform capability
   Each platform implements this in its own HAL layer, allowing the upper layers to query the correct size before allocating:

cdsError_t dsGetMaxHdcpKeySize(size_t *maxSize);

Contract

• The caller queries dsGetMaxHdcpKeySize(), allocates hdcpKey accordingly, and frees it after dsEnableHDCP() returns.
• The HAL validates the incoming keySize against the platform maximum and returns dsERR_INVALID_PARAM if it is out of range.
• The HAL never owns the buffer.

Benefits

Removes the hardcoded HDCP_KEY_MAX_SIZE dependency from the common header
Each platform allocates only what it needs — no over-allocation or under-allocation
Platform capability is discoverable at runtime via dsGetMaxHdcpKeySize()
Struct and API contract remain consistent across all platforms

[SUGANTHAP]

Thanks @srinivasgtl
Now I understand the expectation from the SoC team. Based on this, my understanding of the new implementation is as follows:
There are two scenarios:

1. SoC vendor with the new function dsGetMaxHdcpKeySize()
   In this case, the dynamic pointer will obtain the HDCP key size using this new function.
2. SoC vendor without the new function dsGetMaxHdcpKeySize()
   In this case, the dynamic pointer will determine the HDCP key size using HDCP_KEY_MAX_SIZE.

[Ulrond]

Triage note (#192, ~55 days old, last activity ~36 days ago, BLOCKED):

Update dsAVDTypes.h for HDCP key buffer size improvement. Status: BLOCKED.

Suggested next step: author check-in. The 36-day staleness is on the edge — not yet abandoned but losing momentum. Reviewer engagement could resolve.