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
| ||
|
Message-ID: <CADnq5_PaXmFa6N_2-NRp7_2+m3TYt8s--4aYm1UTnQKXDUhwYw@mail.gmail.com> Date: Mon, 25 Sep 2023 13:56:16 -0400 From: Alex Deucher <alexdeucher@...il.com> To: Kees Cook <keescook@...omium.org> Cc: Christian König <christian.koenig@....com>, David Airlie <airlied@...il.com>, Tejas Upadhyay <tejas.upadhyay@...el.com>, Emma Anholt <emma@...olt.net>, Tom Rix <trix@...hat.com>, llvm@...ts.linux.dev, dri-devel@...ts.freedesktop.org, Chris Wilson <chris@...is-wilson.co.uk>, Prike Liang <Prike.Liang@....com>, Huang Rui <ray.huang@....com>, Gerd Hoffmann <kraxel@...hat.com>, Andrzej Hajda <andrzej.hajda@...el.com>, Marijn Suijten <marijn.suijten@...ainline.org>, Matthew Brost <matthew.brost@...el.com>, Karol Herbst <kherbst@...hat.com>, Neil Armstrong <neil.armstrong@...aro.org>, amd-gfx@...ts.freedesktop.org, Kuogee Hsieh <quic_khsieh@...cinc.com>, Nathan Chancellor <nathan@...nel.org>, VMware Graphics Reviewers <linux-graphics-maintainer@...are.com>, Ben Skeggs <bskeggs@...hat.com>, Andi Shyti <andi.shyti@...ux.intel.com>, nouveau@...ts.freedesktop.org, David Airlie <airlied@...hat.com>, virtualization@...ts.linux-foundation.org, linux-hardening@...r.kernel.org, Lijo Lazar <lijo.lazar@....com>, Yifan Zhang <yifan1.zhang@....com>, linux-arm-msm@...r.kernel.org, intel-gfx@...ts.freedesktop.org, Kevin Wang <kevin1.wang@....com>, Abhinav Kumar <quic_abhinavk@...cinc.com>, Melissa Wen <mwen@...lia.com>, Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, Gurchetan Singh <gurchetansingh@...omium.org>, Maxime Ripard <mripard@...nel.org>, Rodrigo Vivi <rodrigo.vivi@...el.com>, Evan Quan <evan.quan@....com>, Sean Paul <sean@...rly.run>, Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>, Xiaojian Du <Xiaojian.Du@....com>, Le Ma <le.ma@....com>, freedreno@...ts.freedesktop.org, Bjorn Andersson <andersson@...nel.org>, "Pan, Xinhui" <Xinhui.Pan@....com>, Nick Desaulniers <ndesaulniers@...gle.com>, linux-kernel@...r.kernel.org, Alex Deucher <alexander.deucher@....com>, Nirmoy Das <nirmoy.das@...el.com>, Lang Yu <Lang.Yu@....com>, John Harrison <john.c.harrison@...el.com>, Hawking Zhang <Hawking.Zhang@....com> Subject: Re: [PATCH 1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by On Mon, Sep 25, 2023 at 1:52 PM Kees Cook <keescook@...omium.org> wrote: > > On Mon, Sep 25, 2023 at 08:30:30AM +0200, Christian König wrote: > > Am 22.09.23 um 19:41 schrieb Alex Deucher: > > > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook <keescook@...omium.org> wrote: > > > > Prepare for the coming implementation by GCC and Clang of the __counted_by > > > > attribute. Flexible array members annotated with __counted_by can have > > > > their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > > > > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > > > > functions). > > > > > > > > As found with Coccinelle[1], add __counted_by for struct smu10_voltage_dependency_table. > > > > > > > > [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci > > > > > > > > Cc: Evan Quan <evan.quan@....com> > > > > Cc: Alex Deucher <alexander.deucher@....com> > > > > Cc: "Christian König" <christian.koenig@....com> > > > > Cc: "Pan, Xinhui" <Xinhui.Pan@....com> > > > > Cc: David Airlie <airlied@...il.com> > > > > Cc: Daniel Vetter <daniel@...ll.ch> > > > > Cc: Xiaojian Du <Xiaojian.Du@....com> > > > > Cc: Huang Rui <ray.huang@....com> > > > > Cc: Kevin Wang <kevin1.wang@....com> > > > > Cc: amd-gfx@...ts.freedesktop.org > > > > Cc: dri-devel@...ts.freedesktop.org > > > > Signed-off-by: Kees Cook <keescook@...omium.org> > > > Acked-by: Alex Deucher <alexander.deucher@....com> > > > > Mhm, I'm not sure if this is a good idea. That is a structure filled in by > > the firmware, isn't it? > > > > That would imply that we might need to byte swap count before it is > > checkable. > > The script found this instance because of this: > > static int smu10_get_clock_voltage_dependency_table(struct pp_hwmgr *hwmgr, > struct smu10_voltage_dependency_table **pptable, > uint32_t num_entry, const DpmClock_t *pclk_dependency_table) > { > uint32_t i; > struct smu10_voltage_dependency_table *ptable; > > ptable = kzalloc(struct_size(ptable, entries, num_entry), GFP_KERNEL); > if (NULL == ptable) > return -ENOMEM; > > ptable->count = num_entry; > > So the implication is that it's native byte order... but you tell me! I > certainly don't want this annotation if it's going to break stuff. :) In this case, the code is for an integrated GPU in an x86 CPU so the firmware and driver endianness match. You wouldn't find a stand alone dGPU that uses this structure. In this case it's ok. False alarm. Alex
Powered by blists - more mailing lists