linux-kernel - Re: [PATCH v2 2/2] drm/ci: validate drm/msm XML register files against schema

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 10 May 2024 10:37:03 -0300
From: Helen Koike <helen.koike@...labora.com>
To: Abhinav Kumar <quic_abhinavk@...cinc.com>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
 Marijn Suijten <marijn.suijten@...ainline.org>,
 David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] drm/ci: validate drm/msm XML register files
 against schema



On 03/05/2024 21:07, Abhinav Kumar wrote:
> 
> 
> On 5/3/2024 5:02 PM, Dmitry Baryshkov wrote:
>> On Sat, 4 May 2024 at 01:38, Abhinav Kumar <quic_abhinavk@...cinc.com> 
>> wrote:
>>>
>>>
>>>
>>> On 5/3/2024 1:20 PM, Dmitry Baryshkov wrote:
>>>> On Fri, 3 May 2024 at 22:42, Abhinav Kumar 
>>>> <quic_abhinavk@...cinc.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 5/3/2024 11:15 AM, Dmitry Baryshkov wrote:
>>>>>> In order to validate drm/msm register definition files against 
>>>>>> schema,
>>>>>> reuse the nodebugfs build step. The validation entry is guarded by
>>>>>> the EXPERT Kconfig option and we don't want to enable that option for
>>>>>> all the builds.
>>>>>>
>>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
>>>>>> ---
>>>>>>     drivers/gpu/drm/ci/build.sh  | 3 +++
>>>>>>     drivers/gpu/drm/ci/build.yml | 1 +
>>>>>>     2 files changed, 4 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/ci/build.sh 
>>>>>> b/drivers/gpu/drm/ci/build.sh
>>>>>> index 106f2d40d222..28a495c0c39c 100644
>>>>>> --- a/drivers/gpu/drm/ci/build.sh
>>>>>> +++ b/drivers/gpu/drm/ci/build.sh
>>>>>> @@ -12,6 +12,9 @@ rm -rf .git/rebase-apply
>>>>>>     apt-get update
>>>>>>     apt-get install -y libssl-dev
>>>>>>
>>>>>> +# for msm header validation
>>>>>> +apt-get install -y python3-lxml
>>>>>> +
>>>>>>     if [[ "$KERNEL_ARCH" = "arm64" ]]; then
>>>>>>         GCC_ARCH="aarch64-linux-gnu"
>>>>>>         DEBIAN_ARCH="arm64"
>>>>>> diff --git a/drivers/gpu/drm/ci/build.yml 
>>>>>> b/drivers/gpu/drm/ci/build.yml
>>>>>> index 17ab38304885..9c198239033d 100644
>>>>>> --- a/drivers/gpu/drm/ci/build.yml
>>>>>> +++ b/drivers/gpu/drm/ci/build.yml
>>>>>> @@ -106,6 +106,7 @@ build-nodebugfs:arm64:
>>>>>>       extends: .build:arm64
>>>>>>       variables:
>>>>>>         DISABLE_KCONFIGS: "DEBUG_FS"
>>>>>> +    ENABLE_KCONFIGS: "EXPERT DRM_MSM_VALIDATE_XML"
>>>>>>
>>>>>
>>>>> Wouldnt this end up enabling DRM_MSM_VALIDATE_XML for any arm64 
>>>>> device.
>>>>>
>>>>> Cant we make this build rule msm specific?
>>>>
>>>> No need to. We just need to validate the files at least once during
>>>> the whole pipeline build.
>>>>
>>>
>>> ah okay, today the arm64 config anyway sets all arm64 vendor drm configs
>>> to y.
>>>
>>> A couple of more questions:
>>>
>>> 1) Why is this enabled only for no-debugfs option?
>>> 2) Will there be any concerns from other vendors to enable CONFIG_EXPERT
>>> in their CI runs as the arm64 config is shared across all arm64 vendors.
>>
>> I don't get the second question. This option is only enabled for
>> no-debugfs, which isn't used for execution.
>>
> 
> Ah I see, makes sense.
> 
>> I didn't want to add an extra build stage, just for the sake of
>> validating regs against the schema, nor did I want EXPERT to find its
>> way into the actual running kernels.
>>
> 
> This answered my second question actually. That basically I didnt also 
> want EXPERT to find its way into actual running kernels.
> 
> Hence, I am fine with this change now
> 
> Reviewed-by: Abhinav Kumar <quic_abhinavk@...cinc.com>
> 
> But, I will wait to hear from helen, vignesh about what they think of this.


lgfm

Acked-by: Helen Koike <helen.koike@...labora.com>

Thanks
Helen