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: <alpine.DEB.2.20.1801311836320.3707@hadrien>
Date:   Wed, 31 Jan 2018 18:38:55 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
cc:     cocci@...teme.lip6.fr,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Himanshu Jha <himanshujha199640@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org,
        Gilles Muller <Gilles.Muller@...6.fr>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nicolas Palix <nicolas.palix@...g.fr>
Subject: Re: [v2] Coccinelle: zalloc-simple: Delete function “kmem_cache_alloc” from SmPL rules



On Wed, 31 Jan 2018, SF Markus Elfring wrote:

> > I removed the blank line at EOF,
> > then applied to linux-kbuild/misc.
>
> I have taken another look at this script for the semantic patch language.
> I imagined that I could refactor the shown SmPL disjunctions a bit.
> But I noticed then that these SmPL rules contain a development mistake.
>
> The deletion for a call of the function “memset” depends on the specification
> that a size determination is passed by the expression “E1”.
> The function “kmem_cache_alloc” was specified despite of the technical detail
> that this function does not get a parameter passed which would correspond
> to such a size information.
> https://elixir.free-electrons.com/linux/v4.15/source/tools/testing/radix-tree/linux/slab.h#L14
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/tools/testing/radix-tree/linux/slab.h?id=537659c08a7da298aa748854f65f2aa1f31b1378#n14
>
> Thus I suggest to remove it from the first two SmPL rules and omit the rule “r4”.
> Will the rule set be more consistent then?

If E1 is not bound by the kem_cache_alloc rule, then it will match
anything.  The user can check if it is appropriate.

Another option would be to use the type of the variable storing the result
of the call to compute the expected size.  Feel free to send a patch.

julia

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ