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: <20190607190047.C3E7A20868@mail.kernel.org>
Date:   Fri, 07 Jun 2019 12:00:47 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Iurii Zaikin <yzaikin@...gle.com>
Cc:     Brendan Higgins <brendanhiggins@...gle.com>,
        frowand.list@...il.com, gregkh@...uxfoundation.org,
        jpoimboe@...hat.com, keescook@...gle.com,
        kieran.bingham@...asonboard.com, mcgrof@...nel.org,
        peterz@...radead.org, robh@...nel.org, shuah@...nel.org,
        tytso@....edu, yamada.masahiro@...ionext.com,
        devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        kunit-dev@...glegroups.com, linux-doc@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-nvdimm@...ts.01.org, linux-um@...ts.infradead.org,
        Alexander.Levin@...rosoft.com, Tim.Bird@...y.com,
        amir73il@...il.com, dan.carpenter@...cle.com, daniel@...ll.ch,
        jdike@...toit.com, joel@....id.au, julia.lawall@...6.fr,
        khilman@...libre.com, knut.omang@...cle.com, logang@...tatee.com,
        mpe@...erman.id.au, pmladek@...e.com, rdunlap@...radead.org,
        richard@....at, rientjes@...gle.com, rostedt@...dmis.org,
        wfg@...ux.intel.com
Subject: Re: [PATCH v4 17/18] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()

Quoting Iurii Zaikin (2019-06-05 18:29:42)
> On Fri, May 17, 2019 at 11:22 AM Stephen Boyd <sboyd@...nel.org> wrote:
> >
> > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > new file mode 100644
> > > index 0000000000000..fe0f2bae66085
> > > --- /dev/null
> > > +++ b/kernel/sysctl-test.c
> > > +
> > > +
> > > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > > +{
> > > +       struct ctl_table table = {
> > > +               .procname = "foo",
> > > +               .data           = &test_data.int_0001,
> > > +               .maxlen         = sizeof(int),
> > > +               .mode           = 0644,
> > > +               .proc_handler   = proc_dointvec,
> > > +               .extra1         = &i_zero,
> > > +               .extra2         = &i_one_hundred,
> > > +       };
> > > +       char input[] = "-9";
> > > +       size_t len = sizeof(input) - 1;
> > > +       loff_t pos = 0;
> > > +
> > > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > > +       KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > > +       KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
> >
> > Is the casting necessary? Or can the macro do a type coercion of the
> > second parameter based on the first type?
>  Data field is defined as void* so I believe casting is necessary to
> dereference it as a pointer to an array of ints. I don't think the
> macro should do any type coercion that == operator wouldn't do.
>  I did change the cast to make it more clear that it's a pointer to an
> array of ints being dereferenced.

Ok, I still wonder if we should make KUNIT_EXPECT_EQ check the types on
both sides and cause a build warning/error if the types aren't the same.
This would be similar to our min/max macros that complain about
mismatched types in the comparisons. Then if a test developer needs to
convert one type or the other they could do so with a
KUNIT_EXPECT_EQ_T() macro that lists the types to coerce both sides to
explicitly.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ