Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

2019-09-12 Thread Harry Wentland
On 2019-09-12 2:54 a.m., Ramalingam C wrote:
> On 2019-09-12 at 00:15:32 +, Harry Wentland wrote:
>> Adding a couple AMD guys.
>>
>> I know this is already merged but I have a few questions after some
>> internal discussions.
>>
>> On 2019-05-07 12:27 p.m., Ramalingam C wrote:
>>> On every hdcp revocation check request SRM is read from fw file
>>> /lib/firmware/display_hdcp_srm.bin
>>>
>>
>> According to section 5 of the HDCP 2.3 spec [1] a device compliant with
>> HDCP 2.0 and higher must be capable of storing and updating the SRM in
>> non-volatile memory. Section 5.2 describes how this SRM needs to be
>> updated when a new version is served alongside protected content.
>>
>> Isn't /lib/firmware intended for static firmware making updates to the
>> folder problematic for anyone but the system's package maintainer? I've
>> heard /lib might even be treated as read-only in certain environments.
>> This would mean it'd be impossible to support HDCP 2.x on those systems.
>>
>> Wouldn't it be easier to provide a sysfs entry for SRM that allows
>> userspace (e.g. system startup/shutdown scripts) to (a) retrieve the SRM
>> from the HDCP implementation for non-volatile storage and (b) to pass
>> the SRM to the HDCP implementation for revocation checking?
> 
> This uAPI is decided considering below points:
> 
> userspace will handle the non-volatile storage of the SRM table and it's 
> upgrade
> with latest versions received from content providers etc.
> 
> Prior to any HDCP auth request userspace will write the latest SRM into
> the /lib/firmware.
> 
> And regarding the interface, binary sysfs based implementation [1] was 
> opposed by Greg KH.
> And after the discussion on different alternate i/fs [2] request
> firmware is choosen.
> 
> [1]. https://patchwork.freedesktop.org/patch/296442/?series=57232=5uAPI
> [2]. https://patchwork.freedesktop.org/patch/296439/?series=57232=5
> 
> I hope this addresses the questions above.
> 

Interesting discussion. Thanks for sharing.

It sounds like Greg's main concern was with the fact that DRM parses the
binary.

In our case we'll need to pass the blob to FW without touching it. A
device sysfs sounds like a better use-case for that.

On the other hand certain people are interested to have a non-FW
approach to content protection for which your approach seems to work best.

I still don't know how this solution can get HDCP 2.x certified. I was
under the impression HDCP 2.x required a protected execution environment
with stricter requirements than x86 kernel space can provide.

Harry

> -Ram
> 
> 
>>
>> [1]
>> https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf
>>
>> Thanks,
>> Harry
>>
>>> SRM table is parsed and stored at drm_hdcp.c, with functions exported
>>> for the services for revocation check from drivers (which
>>> implements the HDCP authentication)
>>>
>>> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
>>>
>>> v2:
>>>   moved the uAPI to request_firmware_direct() [Daniel]
>>> v3:
>>>   kdoc added. [Daniel]
>>>   srm_header unified and bit field definitions are removed. [Daniel]
>>>   locking improved. [Daniel]
>>>   vrl length violation is fixed. [Daniel]
>>> v4:
>>>   s/__swab16/be16_to_cpu [Daniel]
>>>   be24_to_cpu is done through a global func [Daniel]
>>>   Unused variables are removed. [Daniel]
>>>   unchecked return values are dropped from static funcs [Daniel]
>>>
>>> Signed-off-by: Ramalingam C 
>>> Acked-by: Satyeshwar Singh 
>>> Reviewed-by: Daniel Vetter 
>>> ---
>>>  Documentation/gpu/drm-kms-helpers.rst |   6 +
>>>  drivers/gpu/drm/Makefile  |   2 +-
>>>  drivers/gpu/drm/drm_hdcp.c| 333 ++
>>>  drivers/gpu/drm/drm_internal.h|   4 +
>>>  drivers/gpu/drm/drm_sysfs.c   |   2 +
>>>  include/drm/drm_hdcp.h|  24 ++
>>>  6 files changed, 370 insertions(+), 1 deletion(-)
>>>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
>>>
>>> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
>>> b/Documentation/gpu/drm-kms-helpers.rst
>>> index 14102ae035dc..0fe726a6ee67 100644
>>> --- a/Documentation/gpu/drm-kms-helpers.rst
>>> +++ b/Documentation/gpu/drm-kms-helpers.rst
>>> @@ -181,6 +181,12 @@ Panel Helper Reference
>>>  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
>>> :export:
>>>
>>> +HDCP Helper Functions Reference
>>> +===
>>> +
>>> +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
>>> +   :export:
>>> +
>>>  Display Port Helper Functions Reference
>>>  ===
>>>
>>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>>> index 72f5036d9bfa..dd02e9dec810 100644
>>> --- a/drivers/gpu/drm/Makefile
>>> +++ b/drivers/gpu/drm/Makefile
>>> @@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.o \
>>> drm_plane.o drm_color_mgmt.o drm_print.o \
>>> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
>>> 

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

2019-09-12 Thread Harry Wentland
Adding a couple AMD guys.

I know this is already merged but I have a few questions after some
internal discussions.

On 2019-05-07 12:27 p.m., Ramalingam C wrote:
> On every hdcp revocation check request SRM is read from fw file
> /lib/firmware/display_hdcp_srm.bin
> 

According to section 5 of the HDCP 2.3 spec [1] a device compliant with
HDCP 2.0 and higher must be capable of storing and updating the SRM in
non-volatile memory. Section 5.2 describes how this SRM needs to be
updated when a new version is served alongside protected content.

Isn't /lib/firmware intended for static firmware making updates to the
folder problematic for anyone but the system's package maintainer? I've
heard /lib might even be treated as read-only in certain environments.
This would mean it'd be impossible to support HDCP 2.x on those systems.

Wouldn't it be easier to provide a sysfs entry for SRM that allows
userspace (e.g. system startup/shutdown scripts) to (a) retrieve the SRM
from the HDCP implementation for non-volatile storage and (b) to pass
the SRM to the HDCP implementation for revocation checking?

[1]
https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf

Thanks,
Harry

> SRM table is parsed and stored at drm_hdcp.c, with functions exported
> for the services for revocation check from drivers (which
> implements the HDCP authentication)
> 
> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> 
> v2:
>   moved the uAPI to request_firmware_direct() [Daniel]
> v3:
>   kdoc added. [Daniel]
>   srm_header unified and bit field definitions are removed. [Daniel]
>   locking improved. [Daniel]
>   vrl length violation is fixed. [Daniel]
> v4:
>   s/__swab16/be16_to_cpu [Daniel]
>   be24_to_cpu is done through a global func [Daniel]
>   Unused variables are removed. [Daniel]
>   unchecked return values are dropped from static funcs [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Acked-by: Satyeshwar Singh 
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms-helpers.rst |   6 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_hdcp.c| 333 ++
>  drivers/gpu/drm/drm_internal.h|   4 +
>  drivers/gpu/drm/drm_sysfs.c   |   2 +
>  include/drm/drm_hdcp.h|  24 ++
>  6 files changed, 370 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 14102ae035dc..0fe726a6ee67 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -181,6 +181,12 @@ Panel Helper Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
> :export:
> 
> +HDCP Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> +   :export:
> +
>  Display Port Helper Functions Reference
>  ===
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 72f5036d9bfa..dd02e9dec810 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> -   drm_atomic_uapi.o
> +   drm_atomic_uapi.o drm_hdcp.o
> 
>  drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o 
> drm_dma.o drm_scatter.o drm_lock.o
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> new file mode 100644
> index ..5e5409505c31
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * Authors:
> + * Ramalingam C 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct hdcp_srm {
> +   u32 revoked_ksv_cnt;
> +   u8 *revoked_ksv_list;
> +
> +   /* Mutex to protect above struct member */
> +   struct mutex mutex;
> +} *srm_data;
> +
> +static inline void drm_hdcp_print_ksv(const u8 *ksv)
> +{
> +   DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
> + ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
> +}
> +
> +static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
> +{
> +   u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> +
> +   while (parsed_bytes < vrls_length) {
> +   vrl_ksv_cnt = *buf;
> +   ksv_count += vrl_ksv_cnt;
> +
> +   vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> +   buf += vrl_sz;
> +   parsed_bytes 

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

2019-09-12 Thread Ramalingam C
On 2019-09-12 at 00:15:32 +, Harry Wentland wrote:
> Adding a couple AMD guys.
> 
> I know this is already merged but I have a few questions after some
> internal discussions.
> 
> On 2019-05-07 12:27 p.m., Ramalingam C wrote:
> > On every hdcp revocation check request SRM is read from fw file
> > /lib/firmware/display_hdcp_srm.bin
> > 
> 
> According to section 5 of the HDCP 2.3 spec [1] a device compliant with
> HDCP 2.0 and higher must be capable of storing and updating the SRM in
> non-volatile memory. Section 5.2 describes how this SRM needs to be
> updated when a new version is served alongside protected content.
> 
> Isn't /lib/firmware intended for static firmware making updates to the
> folder problematic for anyone but the system's package maintainer? I've
> heard /lib might even be treated as read-only in certain environments.
> This would mean it'd be impossible to support HDCP 2.x on those systems.
> 
> Wouldn't it be easier to provide a sysfs entry for SRM that allows
> userspace (e.g. system startup/shutdown scripts) to (a) retrieve the SRM
> from the HDCP implementation for non-volatile storage and (b) to pass
> the SRM to the HDCP implementation for revocation checking?

This uAPI is decided considering below points:

userspace will handle the non-volatile storage of the SRM table and it's upgrade
with latest versions received from content providers etc.

Prior to any HDCP auth request userspace will write the latest SRM into
the /lib/firmware.

And regarding the interface, binary sysfs based implementation [1] was opposed 
by Greg KH.
And after the discussion on different alternate i/fs [2] request
firmware is choosen.

[1]. https://patchwork.freedesktop.org/patch/296442/?series=57232=5uAPI
[2]. https://patchwork.freedesktop.org/patch/296439/?series=57232=5

I hope this addresses the questions above.

-Ram


> 
> [1]
> https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf
> 
> Thanks,
> Harry
> 
> > SRM table is parsed and stored at drm_hdcp.c, with functions exported
> > for the services for revocation check from drivers (which
> > implements the HDCP authentication)
> > 
> > This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> > 
> > v2:
> >   moved the uAPI to request_firmware_direct() [Daniel]
> > v3:
> >   kdoc added. [Daniel]
> >   srm_header unified and bit field definitions are removed. [Daniel]
> >   locking improved. [Daniel]
> >   vrl length violation is fixed. [Daniel]
> > v4:
> >   s/__swab16/be16_to_cpu [Daniel]
> >   be24_to_cpu is done through a global func [Daniel]
> >   Unused variables are removed. [Daniel]
> >   unchecked return values are dropped from static funcs [Daniel]
> > 
> > Signed-off-by: Ramalingam C 
> > Acked-by: Satyeshwar Singh 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  Documentation/gpu/drm-kms-helpers.rst |   6 +
> >  drivers/gpu/drm/Makefile  |   2 +-
> >  drivers/gpu/drm/drm_hdcp.c| 333 ++
> >  drivers/gpu/drm/drm_internal.h|   4 +
> >  drivers/gpu/drm/drm_sysfs.c   |   2 +
> >  include/drm/drm_hdcp.h|  24 ++
> >  6 files changed, 370 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_hdcp.c
> > 
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> > b/Documentation/gpu/drm-kms-helpers.rst
> > index 14102ae035dc..0fe726a6ee67 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -181,6 +181,12 @@ Panel Helper Reference
> >  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
> > :export:
> > 
> > +HDCP Helper Functions Reference
> > +===
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> > +   :export:
> > +
> >  Display Port Helper Functions Reference
> >  ===
> > 
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 72f5036d9bfa..dd02e9dec810 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> > -   drm_atomic_uapi.o
> > +   drm_atomic_uapi.o drm_hdcp.o
> > 
> >  drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o 
> > drm_dma.o drm_scatter.o drm_lock.o
> >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> > new file mode 100644
> > index ..5e5409505c31
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_hdcp.c
> > @@ -0,0 +1,333 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Intel Corporation.
> > + *
> > + * Authors:
> > + * Ramalingam C 
> > + */
> > +
> > 

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

2019-09-11 Thread Deucher, Alexander
> -Original Message-
> From: Wentland, Harry 
> Sent: Wednesday, September 11, 2019 8:16 PM
> To: Ramalingam C ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> daniel.vet...@intel.com
> Cc: gwan-gyeong@intel.com; Kumar, Ranjeet
> ; Deucher, Alexander
> ; Lakha, Bhawanpreet
> 
> Subject: Re: [PATCH v7 04/11] drm: revocation check at drm subsystem
> 
> Adding a couple AMD guys.
> 
> I know this is already merged but I have a few questions after some internal
> discussions.
> 
> On 2019-05-07 12:27 p.m., Ramalingam C wrote:
> > On every hdcp revocation check request SRM is read from fw file
> > /lib/firmware/display_hdcp_srm.bin
> >
> 
> According to section 5 of the HDCP 2.3 spec [1] a device compliant with HDCP
> 2.0 and higher must be capable of storing and updating the SRM in non-
> volatile memory. Section 5.2 describes how this SRM needs to be updated
> when a new version is served alongside protected content.
> 
> Isn't /lib/firmware intended for static firmware making updates to the folder
> problematic for anyone but the system's package maintainer? I've heard /lib
> might even be treated as read-only in certain environments.
> This would mean it'd be impossible to support HDCP 2.x on those systems.
> 
> Wouldn't it be easier to provide a sysfs entry for SRM that allows userspace
> (e.g. system startup/shutdown scripts) to (a) retrieve the SRM from the
> HDCP implementation for non-volatile storage and (b) to pass the SRM to the
> HDCP implementation for revocation checking?

Also, IIRC, for level 1 support, I think the srm parsing has to happen on 
something other than the CPU, so I'm not sure where need to do any parsing in 
software, at least for HDCP 2.x.

Alex

> 
> [1]
> https://www.digital-
> cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_
> 3.pdf
> 
> Thanks,
> Harry
> 
> > SRM table is parsed and stored at drm_hdcp.c, with functions exported
> > for the services for revocation check from drivers (which implements
> > the HDCP authentication)
> >
> > This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> >
> > v2:
> >   moved the uAPI to request_firmware_direct() [Daniel]
> > v3:
> >   kdoc added. [Daniel]
> >   srm_header unified and bit field definitions are removed. [Daniel]
> >   locking improved. [Daniel]
> >   vrl length violation is fixed. [Daniel]
> > v4:
> >   s/__swab16/be16_to_cpu [Daniel]
> >   be24_to_cpu is done through a global func [Daniel]
> >   Unused variables are removed. [Daniel]
> >   unchecked return values are dropped from static funcs [Daniel]
> >
> > Signed-off-by: Ramalingam C 
> > Acked-by: Satyeshwar Singh 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  Documentation/gpu/drm-kms-helpers.rst |   6 +
> >  drivers/gpu/drm/Makefile  |   2 +-
> >  drivers/gpu/drm/drm_hdcp.c| 333
> ++
> >  drivers/gpu/drm/drm_internal.h|   4 +
> >  drivers/gpu/drm/drm_sysfs.c   |   2 +
> >  include/drm/drm_hdcp.h|  24 ++
> >  6 files changed, 370 insertions(+), 1 deletion(-)  create mode 100644
> > drivers/gpu/drm/drm_hdcp.c
> >
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst
> > b/Documentation/gpu/drm-kms-helpers.rst
> > index 14102ae035dc..0fe726a6ee67 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -181,6 +181,12 @@ Panel Helper Reference  .. kernel-doc::
> > drivers/gpu/drm/drm_panel_orientation_quirks.c
> > :export:
> >
> > +HDCP Helper Functions Reference
> > +===
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> > +   :export:
> > +
> >  Display Port Helper Functions Reference
> > ===
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index
> > 72f5036d9bfa..dd02e9dec810 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> > -   drm_atomic_uapi.o
> > +   drm_atomic_uapi.o drm_hdcp.o
> >
> >  drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o
> > drm_context.o drm_dma.o drm_scatter.o drm_lock.o
> >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o diff --git
> > a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c new file
> > mode 100644 index ..5e5409505c31
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_hdcp.c
> > @@ -0,0 +1,333 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Intel Corporation.
> > + *
> > + * Authors:
> > + * Ramalingam C   */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > 

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

2019-07-04 Thread Pekka Paalanen
On Tue,  7 May 2019 21:57:38 +0530
Ramalingam C  wrote:

> On every hdcp revocation check request SRM is read from fw file
> /lib/firmware/display_hdcp_srm.bin
> 
> SRM table is parsed and stored at drm_hdcp.c, with functions exported
> for the services for revocation check from drivers (which
> implements the HDCP authentication)
> 
> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> 
> v2:
>   moved the uAPI to request_firmware_direct() [Daniel]
> v3:
>   kdoc added. [Daniel]
>   srm_header unified and bit field definitions are removed. [Daniel]
>   locking improved. [Daniel]
>   vrl length violation is fixed. [Daniel]
> v4:
>   s/__swab16/be16_to_cpu [Daniel]
>   be24_to_cpu is done through a global func [Daniel]
>   Unused variables are removed. [Daniel]
>   unchecked return values are dropped from static funcs [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Acked-by: Satyeshwar Singh 
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms-helpers.rst |   6 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_hdcp.c| 333 ++
>  drivers/gpu/drm/drm_internal.h|   4 +
>  drivers/gpu/drm/drm_sysfs.c   |   2 +
>  include/drm/drm_hdcp.h|  24 ++
>  6 files changed, 370 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 14102ae035dc..0fe726a6ee67 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -181,6 +181,12 @@ Panel Helper Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
> :export:
>  
> +HDCP Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> +   :export:
> +
>  Display Port Helper Functions Reference
>  ===
>  

...

> +/**
> + * drm_hdcp_check_ksvs_revoked - Check the revoked status of the IDs
> + *
> + * @drm_dev: drm_device for which HDCP revocation check is requested
> + * @ksvs: List of KSVs (HDCP receiver IDs)
> + * @ksv_count: KSV count passed in through @ksvs
> + *
> + * This function reads the HDCP System renewability Message(SRM Table)
> + * from userspace as a firmware and parses it for the revoked HDCP
> + * KSVs(Receiver IDs) detected by DCP LLC. Once the revoked KSVs are known,
> + * revoked state of the KSVs in the list passed in by display drivers are
> + * decided and response is sent.
> + *
> + * SRM should be presented in the name of "display_hdcp_srm.bin".
> + *
> + * Returns:
> + * TRUE on any of the KSV is revoked, else FALSE.

Hi,

this does not seem to be specifying the file format. Since this file is
expected to be provided by vendors and not the driver developers AFAIU,
I think the file format counts as UAPI and needs to be explicitly and
unambiguously specified. Especially as the file or the file format are
not tied to a specific DRM driver or any driver. A searchable reference
to a particular revision of a public specification document could
suffice if such exists.

This doc comment is only kernel internal API. I would also expect UAPI
documentation for the same reason as above.

The Weston work[1] does not validate the UAPI added in this patch.


[1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/48

Thanks,
pq

> + */
> +bool drm_hdcp_check_ksvs_revoked(struct drm_device *drm_dev, u8 *ksvs,
> +  u32 ksv_count)
> +{
> + u32 rev_ksv_cnt, cnt, i, j;
> + u8 *rev_ksv_list;
> +
> + if (!srm_data)
> + return false;
> +
> + mutex_lock(_data->mutex);
> + drm_hdcp_request_srm(drm_dev);
> +
> + rev_ksv_cnt = srm_data->revoked_ksv_cnt;
> + rev_ksv_list = srm_data->revoked_ksv_list;
> +
> + /* If the Revoked ksv list is empty */
> + if (!rev_ksv_cnt || !rev_ksv_list) {
> + mutex_unlock(_data->mutex);
> + return false;
> + }
> +
> + for  (cnt = 0; cnt < ksv_count; cnt++) {
> + rev_ksv_list = srm_data->revoked_ksv_list;
> + for (i = 0; i < rev_ksv_cnt; i++) {
> + for (j = 0; j < DRM_HDCP_KSV_LEN; j++)
> + if (ksvs[j] != rev_ksv_list[j]) {
> + break;
> + } else if (j == (DRM_HDCP_KSV_LEN - 1)) {
> + DRM_DEBUG("Revoked KSV is ");
> + drm_hdcp_print_ksv(ksvs);
> + mutex_unlock(_data->mutex);
> + return true;
> + }
> + /* Move the offset to next KSV in the revoked list */
> + rev_ksv_list += DRM_HDCP_KSV_LEN;
> + }
> +
> + /* Iterate to next ksv_offset */
> + ksvs += 

[Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

2019-05-07 Thread Ramalingam C
On every hdcp revocation check request SRM is read from fw file
/lib/firmware/display_hdcp_srm.bin

SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)

This patch handles the HDCP1.4 and 2.2 versions of SRM table.

v2:
  moved the uAPI to request_firmware_direct() [Daniel]
v3:
  kdoc added. [Daniel]
  srm_header unified and bit field definitions are removed. [Daniel]
  locking improved. [Daniel]
  vrl length violation is fixed. [Daniel]
v4:
  s/__swab16/be16_to_cpu [Daniel]
  be24_to_cpu is done through a global func [Daniel]
  Unused variables are removed. [Daniel]
  unchecked return values are dropped from static funcs [Daniel]

Signed-off-by: Ramalingam C 
Acked-by: Satyeshwar Singh 
Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms-helpers.rst |   6 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_hdcp.c| 333 ++
 drivers/gpu/drm/drm_internal.h|   4 +
 drivers/gpu/drm/drm_sysfs.c   |   2 +
 include/drm/drm_hdcp.h|  24 ++
 6 files changed, 370 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_hdcp.c

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 14102ae035dc..0fe726a6ee67 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -181,6 +181,12 @@ Panel Helper Reference
 .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
:export:
 
+HDCP Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
+   :export:
+
 Display Port Helper Functions Reference
 ===
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..dd02e9dec810 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
-   drm_atomic_uapi.o
+   drm_atomic_uapi.o drm_hdcp.o
 
 drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o 
drm_dma.o drm_scatter.o drm_lock.o
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
new file mode 100644
index ..5e5409505c31
--- /dev/null
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * Authors:
+ * Ramalingam C 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+struct hdcp_srm {
+   u32 revoked_ksv_cnt;
+   u8 *revoked_ksv_list;
+
+   /* Mutex to protect above struct member */
+   struct mutex mutex;
+} *srm_data;
+
+static inline void drm_hdcp_print_ksv(const u8 *ksv)
+{
+   DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
+ ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
+}
+
+static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
+{
+   u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
+
+   while (parsed_bytes < vrls_length) {
+   vrl_ksv_cnt = *buf;
+   ksv_count += vrl_ksv_cnt;
+
+   vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
+   buf += vrl_sz;
+   parsed_bytes += vrl_sz;
+   }
+
+   /*
+* When vrls are not valid, ksvs are not considered.
+* Hence SRM will be discarded.
+*/
+   if (parsed_bytes != vrls_length)
+   ksv_count = 0;
+
+   return ksv_count;
+}
+
+static u32 drm_hdcp_get_revoked_ksvs(const u8 *buf, u8 *revoked_ksv_list,
+u32 vrls_length)
+{
+   u32 parsed_bytes = 0, ksv_count = 0;
+   u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
+
+   do {
+   vrl_ksv_cnt = *buf;
+   vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
+
+   buf++;
+
+   DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
+ vrl_ksv_cnt);
+   memcpy(revoked_ksv_list, buf, vrl_ksv_sz);
+
+   ksv_count += vrl_ksv_cnt;
+   revoked_ksv_list += vrl_ksv_sz;
+   buf += vrl_ksv_sz;
+
+   parsed_bytes += (vrl_ksv_sz + 1);
+   } while (parsed_bytes < vrls_length);
+
+   return ksv_count;
+}
+
+static inline u32 get_vrl_length(const u8 *buf)
+{
+   return drm_hdcp_be24_to_cpu(buf);
+}
+
+static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t count)
+{
+   struct hdcp_srm_header *header;
+   u32 vrl_length, ksv_count;
+
+   if (count < (sizeof(struct hdcp_srm_header) +
+