linux-kernel - Re: [PATCH] coccinelle: ifnullfree: add vfree(), kvfree*() functions

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

Date:   Wed, 2 Sep 2020 09:24:00 +0200 (CEST)
From:   Julia Lawall <julia.lawall@...ia.fr>
To:     Markus Elfring <Markus.Elfring@....de>
cc:     Denis Efremov <efremov@...ux.com>,
        Coccinelle <cocci@...teme.lip6.fr>, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org,
        Gilles Muller <Gilles.Muller@...6.fr>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Kees Cook <keescook@...omium.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nicolas Palix <nicolas.palix@...g.fr>
Subject: Re: [PATCH] coccinelle: ifnullfree: add vfree(), kvfree*()
 functions



On Wed, 2 Sep 2020, Markus Elfring wrote:

> …
> > +++ b/scripts/coccinelle/free/ifnullfree.cocci
> > @@ -20,8 +20,14 @@ expression E;
> >  - if (E != NULL)
> >  (
> >    kfree(E);
> > +|
> > +  kvfree(E);
> >  |
> >    kfree_sensitive(E);
> > +|
> > +  kvfree_sensitive(E, ...);
> > +|
> > +  vfree(E);
> >  |
> >    debugfs_remove(E);
> >  |
>
> Would you ever get into the development mood to move the source code search
> specification “(E);” out of the SmPL disjunction (as it happened for the rule “r”)?
>
>
> > @@ -42,9 +48,10 @@ position p;
> >  @@
> >
> >  * if (E != NULL)
> > -*	\(kfree@p\|kfree_sensitive@p\|debugfs_remove@p\|debugfs_remove_recursive@p\|
> > +*	\(kfree@p\|kvfree@p\|kfree_sensitive@p\|kvfree_sensitive@p\|vfree@p\|
> > +*         debugfs_remove@p\|debugfs_remove_recursive@p\|
> >  *         usb_free_urb@p\|kmem_cache_destroy@p\|mempool_destroy@p\|
> > -*         dma_pool_destroy@p\)(E);
> > +*         dma_pool_destroy@p\)(E, ...);
> …
>
> How do you think about to attach the position variable to the opening parenthesis
> instead of each function name?
>
> +*         dma_pool_destroy\)(@p E, ...);

While it probably impacts few people, this is a really bad idea for org
mode, because org mode colors the thing that the position variable is
attached to.  Having the ( colored would not be very visible.

But even for report mode, this is probably not a good idea for the rare
case where the function name and the argument list are on different lines.

julia

>
>
> Would the number of function call parameters influence such SmPL code any more?
>
> Regards,
> Markus
>