Dear DRM development community,
We'd like to introduce the implementation of the new crtc properties.
First of all, please let me introduce the problem we try to address. With the popularity of electric vehicles, the car vendors have increasing requirement for ensuring the integrity of the critical content on the display. For example, tell-tales are icons to indicate malfunction or operation on a car system. For safty concern, car vendors always want to make sure these icons are not tampered and can be correctly displayed on the instrument cluster.
To address this problem, since modern display control hardware is able to calculate the CRC checksum of the display content, we are thinking of a feature to let userspace specify a region on display, and we can utilize the hardware to calculate the CRC checksum as frames scanned out, and finally, provide the checksum for userspace for validation purpose.
In this case, since the icons themselves are often fixed over static backgrounds, the CRC of the pixels in the region can be known in advance. So one of the usage of the region and corresponding CRC result is that as users know the CRC checksum of the tell-tales in advance, at runtime they can retrieve the CRC value from kernel for validation as frames are scanned out.
We implement this feature and call it checksum region. To let userspace set a region and retrieve the corresponding CRC value, we provide 2 new properties, CHECKSUM_REGION and CHECKSUM_CRC. Both of them are blob properties under CRTC, and the detailed struct of the two properties are listed below. One for userspace to set the region to kernel, and the other for userspace to retrieve CRC values from kernel. Upon userspace submitting the 4 coordinate values with checksum_region_enable true, kernel instructs DC hardware to calculate the CRC value accordingly as frames scanned out. The result CRC value of RGB colors are then stored in CHECKSUM_CRC property, with a reference frame count for userspace to know which frame the CRCs are calculated at.
/**
* struct drm_checksum_region - The enablement and region of checksum_region
* @x_start: Horizontal starting coordinate of the region.
* @y_start: Vertical starting coordinate of the region.
* @x_end: Horizontal ending coordinate of the region.
* @y_end: Vertical ending coordinate of the region.
* @checksum_region_enable: To enable or disable checksum_region.
*
* Userspace uses this structure to configure the region and enablement for
* checksum_region. Userspace should not submit a region out of the displayable
* region because there is nothing to display and need protection.
*/
struct drm_checksum_region {
__u32 x_start;
__u32 y_start;
__u32 x_end;
__u32 y_end;
__u8 checksum_region_enable;
__u8 pad[7];
};
/**
* struct drm_checksum_crc - The CRC value of the corresponding checksum region.
* @crc_r: CRC value of red color.
* @crc_g: CRC value of green color.
* @crc_b: CRC value of blue color.
* @frame_count: a referenced frame count to indicate which frame the CRC values
* are generated at.
*
* Userspace uses this structure to retrieve the CRC values of the current
* checksum region. @frame_count will be reset once a new region is updated or
* it reaches a maximum value. Currently these CRC values are designed to
* be validated with pre-saved CRC values, so userspace doesn't need to concern
* about the algorithm used to compute the CRC.
*/
struct drm_checksum_crc {
__u32 crc_r;
__u32 crc_g;
__u32 crc_b;
__u32 frame_count;
};
To better introduce the usage of this feature, we also have a paired Weston application as an reference app to use secure display via the properties. Please check the Weston application and see how the application set the region and validate the content from the CRC here: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1236
This application can draw patterns on the display, and allow users to set the region and submit it to kernel via properties. With kernel keeping calculating the CRC, this example application takes the first CRC as source CRC, and keeps retrieving the new CRCs at each frame later. By comparing source CRC with the following CRC value, the application can validate if the display content got changed down the road.
Finally, let me briefly introduce the patches. There are 3 patches in this patch series. The first patch is the main patch that contains change to drm, including the new CRTC properties, the property creation function and a update_checksum_region_crc() CRTC callback.
1. drm: Introduce CRTC checksum region and CRC properties
The remaining 2 patches are only related to the processing of region and CRC data in our driver, also listed here for your reference.
2. drm/amd/display: Create checksum_region properties and handle new region update
3. drm/amd/display: Implement the retrieval of checksum_region's CRC data
Thanks for the reading and hope to get your feedback soon!
v2:
- Change the name of secure display to checksum region.
- Move the new properties, their creation function and their state to drm layer.
- Improve comments on the new properties's usage and limitation.
- Add a new CRTC callback update_checksum_region_crc() for updating the CRC checksum to the crc blob.
- Squash patches from 7 to 3.
Alan Liu (3):
drm: Introduce CRTC checksum region and CRC properties
drm/amd/display: Create checksum_region properties and handle new
region update
drm/amd/display: Implement the retrieval of checksum_region's CRC data
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 44 +++++++
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 112 ++++++++++++++++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 14 +++
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 52 ++++++++
drivers/gpu/drm/drm_atomic_state_helper.c | 7 ++
drivers/gpu/drm/drm_atomic_uapi.c | 21 +++-
drivers/gpu/drm/drm_crtc.c | 44 +++++++
include/drm/drm_crtc.h | 43 +++++++
include/uapi/drm/drm_mode.h | 42 +++++++
9 files changed, 368 insertions(+), 11 deletions(-)
--
2.34.1
