linux-kernel - Re: [PATCH 2/2] of: Add array read functions with min/max size limits

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: <CAL_Jsq+Rdw041Xnf8JRocozjeiOCDFaPcAQFM+emjeyrE4W=Jg@mail.gmail.com>
Date:   Thu, 8 Sep 2016 10:38:09 -0500
From:   Rob Herring <robh+dt@...nel.org>
To:     Richard Fitzgerald <rf@...nsource.wolfsonmicro.com>
Cc:     Frank Rowand <frowand.list@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        patches@...nsource.wolfsonmicro.com
Subject: Re: [PATCH 2/2] of: Add array read functions with min/max size limits

On Thu, Sep 8, 2016 at 10:34 AM, Richard Fitzgerald
<rf@...nsource.wolfsonmicro.com> wrote:
> On Thu, 2016-09-08 at 09:46 -0500, Rob Herring wrote:
>> On Tue, Sep 6, 2016 at 10:02 AM, Richard Fitzgerald
>> <rf@...nsource.wolfsonmicro.com> wrote:
>> > Add a new set of array reading functions that take a minimum and
>> > maximum size limit and will fail if the property size is not within
>> > the size limits. This makes it more convenient for drivers that
>> > use variable-size DT arrays which must be bounded at both ends -
>> > data must be at least N entries but must not overflow the array
>> > it is being copied into. It is also more efficient than making this
>> > functionality out of existing public functions and avoids duplication.
>> >
>> > The existing array functions have been left in the API, since there
>> > are a very large number of clients of those functions and their
>> > existing functionality is still useful. This avoids turning a small
>> > API improvement into a major kernel rework.

[...]

>> > @@ -1229,21 +1270,53 @@ EXPORT_SYMBOL_GPL(of_property_read_u32_index);
>> >  int of_property_read_u8_array(const struct device_node *np,
>> >                         const char *propname, u8 *out_values, size_t sz)
>> >  {
>> > -       const u8 *val = of_find_property_value_of_size(np, propname,
>> > -                                               (sz * sizeof(*out_values)),
>> > -                                               0,
>> > -                                               NULL);
>> > -
>> > -       if (IS_ERR(val))
>> > -               return PTR_ERR(val);
>> > -
>> > -       while (sz--)
>> > -               *out_values++ = *val++;
>> > -       return 0;
>> > +       return of_property_read_variable_u8_array(np, propname, out_values,
>> > +                                                 sz, 0);
>>
>> This should be min and max both set to sz.
>
> Passing 0 as max preserves the existing behaviour of these functions of
> only requiring the array to be at least sz long, but not caring if it's
> longer.

Yes, I was just writing to say that after reading patch 1 more carefully.

Rob