[PATCH 0/7] Secure display with new CRTC properties

[Alan Liu]

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 of interest (ROI) 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 ROI pixels can be known in advance. So one of the usage of ROI 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 secure display. To let userspace set ROI and retrieve the corresponding CRC value, we provide 2 new properties, SECURE_DISPLAY_ROI and SECURE_DISPLAY_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 ROI to kernel, and the other for userspace to retrieve CRC values from kernel. Upon userspace submitting the 4 coordinate values with secure_display_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 secure_display_crc property, with a reference frame count for userspace to know which frame the CRCs are calculated at.

/**
 * struct drm_roi - The enablement and region of interest (ROI) of secure display
 * @x_start: Horizontal starting coordinate of ROI.
 * @y_start: Vertical starting coordinate of ROI.
 * @x_end: Horizontal ending coordinate of ROI.
 * @y_end: Vertical ending coordinate of ROI.
 * @secure_display_enable: To enable or disable secure display.
 *
 * Userspace uses this structure to configure the region of interest and
 * enablement for secure display.
 */
struct secure_display_roi {
              u32 x_start;
              u32 y_start;
              u32 x_end;
              u32 y_end;
              u8  secure_display_enable; };

/**
 * struct drm_crc - The CRC value of the corresponding ROI of secure display.
 * @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 value of the current ROI of
 * secure display. @frame_count will be reset once a new ROI is updated or it reaches
 * its maximum value.
 */
struct secure_display_crc {
              u32 crc_r;
              u32 crc_g;
              u32 crc_b;
              u32 crc_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 ROI 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 ROI 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 patch series. In this upstream we have 7 patches. The first 4 patches are adding the new properties to drm, which are the changes to drm layer:
1.                   Add new blob properties for secure display ROI
2.                   Implement set/get functions for secure display ROI properties
3.                   Add new blob properties for secure display CRC
4.                   Implement set/get functions for secure display CRC properties

The remaining 3 patches are only related to the processing of ROI and CRC data in our driver, also listed here for your reference.
5.                   Processing secure display new ROI update in atomic commit
6.                   Implement the retrieval of secure display CRC data
7.                   Block the requests for secure display ROI/CRC until data ready

Thanks for the reading and welcome any advice from your review.


Alan Liu (7):
  drm/amd/display: Add new blob properties for secure display ROI
  drm/amd/display: Implement set/get functions for secure display ROI
    properties
  drm/amd/display: Add new blob properties for secure display CRC
  drm/amd/display: Implement set/get functions for secure display CRC
    properties
  drm/amd/display: Processing secure display new ROI update in atomic
    commit
  drm/amd/display: Implement the retrieval of secure display CRC data
  drm/amd/display: Block the requests for secure display ROI/CRC until
    data ready

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  44 ++++++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  14 ++
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 113 +++++++++++++-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h |  19 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c    | 139 ++++++++++++++++++
 include/uapi/drm/drm_mode.h                   |  39 +++++
 6 files changed, 360 insertions(+), 8 deletions(-)

-- 
2.34.1