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]
Message-ID: <szwu75yxcfxeyvfvrsyuoc3jeoaylydwtlzm3cevmpr3zpmfpo@wrdgbf3w3de2>
Date:   Wed, 12 Apr 2023 20:50:51 +0200
From:   Marijn Suijten <marijn.suijten@...ainline.org>
To:     Abhinav Kumar <quic_abhinavk@...cinc.com>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Kuogee Hsieh <quic_khsieh@...cinc.com>,
        freedreno@...ts.freedesktop.org, quic_sbillaka@...cinc.com,
        airlied@...il.com, andersson@...nel.org, robdclark@...il.com,
        dri-devel@...ts.freedesktop.org, dianders@...omium.org,
        vkoul@...nel.org, agross@...nel.org, daniel@...ll.ch,
        linux-arm-msm@...r.kernel.org, swboyd@...omium.org,
        sean@...rly.run, linux-kernel@...r.kernel.org
Subject: Re: [Freedreno] [PATCH] drm/msm/dpu: add DSC range checking during
 resource reservation

On 2023-04-12 10:48:18, Abhinav Kumar wrote:
[..]
> > The only way to trigger this newly introduced range check is by omitting
> > the DSC_x constants and manually writing e.g. an out-of-range value 10
> > here, or setting DSC_NONE.  This is only allowed for interfaces.
> > 
> 
> Correct, its just working on an implicit understanding that the indices 
> in the catalog

.. this sentence appears to be incomplete: what did you want to say? ..

> which might still be right stick to the RM limits.
> 
> Thats why this is not bad to have.

What do you mean by "RM limits"?  We have constants in the kernel that
both define the maximum number of blocks in these arrays and a
predefined set of ids that block can have.  These are all used in
constant structs in the catalog, so there's nothing "software" or
SoC-specific limiting about this (except what is available in the
arrays).

[..]
> I think kuogee just added this to keep it consistent with other checks 
> present in the RM. So I didnt see any harm with that.

Yep, that's the only reason

> If he did see an issue, i will let him report that here.

If so an out-of-bounds constant was hardcoded in dpu_hw_catalog.c.

> Otherwise, I dont want to spend more time discussing this bounds check 
> when other blocks already have it.

I'll whip up a patch to clear out the extraneous lookup (assuming there
is no other reason/dependency for it to be there...) and can follow that
up with removing these range checks of known-good values in `const
struct` fields.

- Marijn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ