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

[Jani Nikula]

On Wed, 24 May 2023, Simon Ser <contact at emersion.fr> wrote:
> On Tuesday, May 16th, 2023 at 07:39, Alan Liu <HaoPing.Liu at amd.com> wrote:
>
>> 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.
>
> I's strongly advise *not* using the word "secure" here. "Secure" is over-loaded
> with so many different meanings, as a result it's super-unclear what a KMS
> property name "SECURE_FOO" would do. As an example, some people use "secure" to
> refer to Digital Restrictions Management. Something like "CHECKSUM_REGION"
> would much better describe the feature you want to implement IMHO.

Agreed.

On naming, I also think "ROI" is confusing. Nobody's going to know what
it means without looking it up. I think just "region" is much better,
and "of interest" goes without saying. (Why would you specify a region
unless it was "of interest"?)

> Also, please note that IGT already extracts CRCs for testing purposes. Maybe
> there's an opportunity to use the same uAPI here.

It's debugfs, so probably not suitable for uAPI, but there's already a
bunch of crtc infrastructure in drm level to make that happen. Would
seem odd to add two different ways to gather CRCs with no common code.

Just checking, we're talking about CRCs computed at some stage of the
display pipeline in the source, not on the sink, right?

What's the algorithm for the CRCs? Vendor specific? Is the idea that the
userspace is able to compute it and compare, or snapshot multiple CRCs
from kernel and compare them against each other? If the former, then I
assume the userspace is going to be vendor specific too.

What about limitations in the dimensions/location of the region? What
about future compatibility, e.g. if you're interested in *a* region,
surely you might be interested in multiple regions in the future...?
(Not saying this should be implemented now, but would be nice to have
some vague idea how to extend this.)


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center