linux-kernel - Re: [PATCH] drm/amd/display: Use 2-factor allocator calls

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] [day] [month] [year] [list]

Message-ID: <CAGXu5jLMG915BZjYE=+BmfcWknHOZ2n93YakdNBPPfb9P7pyEw@mail.gmail.com>
Date:   Thu, 5 Jul 2018 08:55:04 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Michel Dänzer <michel@...nzer.net>
Cc:     Alex Deucher <alexander.deucher@....com>,
        amd-gfx list <amd-gfx@...ts.freedesktop.org>,
        Tony Cheng <Tony.Cheng@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Maling list - DRI developers 
        <dri-devel@...ts.freedesktop.org>,
        Vitaly Prosyak <vitaly.prosyak@....com>,
        Harry Wentland <harry.wentland@....com>
Subject: Re: [PATCH] drm/amd/display: Use 2-factor allocator calls

On Thu, Jul 5, 2018 at 6:37 AM, Michel Dänzer <michel@...nzer.net> wrote:
> On 2018-07-04 07:27 PM, Kees Cook wrote:
>> As already done treewide, switch from open-coded multiplication to
>> 2-factor allocation helper.
>>
>> Signed-off-by: Kees Cook <keescook@...omium.org>
>> ---
>>  drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
>> index 98edaefa2b47..ee69c949bfbf 100644
>> --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
>> +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
>> @@ -1723,8 +1723,8 @@ bool  mod_color_calculate_curve(enum dc_transfer_func_predefined trans,
>>               kvfree(rgb_regamma);
>>       } else if (trans == TRANSFER_FUNCTION_HLG ||
>>               trans == TRANSFER_FUNCTION_HLG12) {
>> -             rgb_regamma = kvzalloc(sizeof(*rgb_regamma) *
>> -                                    (MAX_HW_POINTS + _EXTRA_POINTS),
>> +             rgb_regamma = kvcalloc(MAX_HW_POINTS + _EXTRA_POINTS,
>> +                                    sizeof(*rgb_regamma),
>>                                      GFP_KERNEL);
>>               if (!rgb_regamma)
>>                       goto rgb_regamma_alloc_fail;
>> @@ -1802,8 +1802,8 @@ bool  mod_color_calculate_degamma_curve(enum dc_transfer_func_predefined trans,
>>               kvfree(rgb_degamma);
>>       } else if (trans == TRANSFER_FUNCTION_HLG ||
>>               trans == TRANSFER_FUNCTION_HLG12) {
>> -             rgb_degamma = kvzalloc(sizeof(*rgb_degamma) *
>> -                                    (MAX_HW_POINTS + _EXTRA_POINTS),
>> +             rgb_degamma = kvcalloc(MAX_HW_POINTS + _EXTRA_POINTS,
>> +                                    sizeof(*rgb_degamma),
>>                                      GFP_KERNEL);
>>               if (!rgb_degamma)
>>                       goto rgb_degamma_alloc_fail;
>>
>
> Since the values are constant, kvcalloc incurs the overflow checking
> overhead for no gain.

The way the macros are designed, they'll get entirely optimized away
in that case:
http://lkml.kernel.org/r/CAGXu5jLw9kMZRkzL_Q7JdyyprntHF6bdVSE_vjyzect3CenDng@mail.gmail.com

Using this patch means if the code ever changes away from constants,
it'll still be safe. And static checkers won't yell about the
open-coded multiplication here. So it's only up-sides. :)

-Kees

-- 
Kees Cook
Pixel Security