[PATCH v2] drm/nouveau/secboot: remove VLA usage

[Kees Cook]

On Wed, May 23, 2018 at 5:36 PM, Ben Skeggs <bskeggs at redhat.com> wrote:
> On Thu, May 24, 2018 at 8:48 AM, Kees Cook <keescook at chromium.org> wrote:
>> On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook <keescook at chromium.org> wrote:
>>> On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs <skeggsb at gmail.com> wrote:
>>>> On 14 March 2018 at 21:08, Thierry Reding <thierry.reding at gmail.com> wrote:
>>>>> On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote:
>>>>>> In preparation to enabling -Wvla, remove VLA. In this particular
>>>>>> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local
>>>>>> variable cmdline_size. Also, remove cmdline_size as it is not
>>>>>> actually useful anymore.
>>>>>>
>>>>>> The use of stack Variable Length Arrays needs to be avoided, as they
>>>>>> can be a vector for stack exhaustion, which can be both a runtime bug
>>>>>> or a security flaw. Also, in general, as code evolves it is easy to
>>>>>> lose track of how big a VLA can get. Thus, we can end up having runtime
>>>>>> failures that are hard to debug.
>>>>>>
>>>>>> Also, fixed as part of the directive to remove all VLAs from
>>>>>> the kernel: https://lkml.org/lkml/2018/3/7/621
>>>>>>
>>>>>> Signed-off-by: Gustavo A. R. Silva <gustavo at embeddedor.com>
>>>>>> ---
>>>>>> Changes in v2:
>>>>>>  - Use sizeof(buf) instead of NVKM_MSGQUEUE_CMDLINE_SIZE. This change
>>>>>>    is based on the feedback provided by David Laight. Thanks David.
>>>>>>
>>>>>>  drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c | 7 +++----
>>>>>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>>>>
>>>>> Reviewed-by: Thierry Reding <treding at nvidia.com>
>>>> Thanks everyone.  I've taken the patch in my tree.
>>>
>>> Hi!
>>>
>>> Just checking in on this -- I don't see this patch in linux-next. Is
>>> this queued somewhere else?
>>
>> Hi, it's been another month; I still don't see this in linux-next.
>> Daniel, can this go via drm-misc?
> It's already queued in drm-next.

Ah-ha, great, thanks! Looks like I just got unlucky with linux-next
pausing on the 17th and this getting committed on the 18th. :) But,
yes, I see it now:
https://cgit.freedesktop.org/drm/drm/commit/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c?id=7bf5b70befd7817b9e42acbd2291b2042ea1bf81

-Kees

-- 
Kees Cook
Pixel Security