linux-kernel - Re: Coccinelle: zalloc-simple: Delete function "kmem_cache

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.1802011125460.3135@hadrien>
Date:   Thu, 1 Feb 2018 11:27:19 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
cc:     cocci@...teme.lip6.fr, Gilles Muller <Gilles.Muller@...6.fr>,
        Himanshu Jha <himanshujha199640@...il.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: Coccinelle: zalloc-simple: Delete function "kmem_cache_alloc"
 from SmPL rules



On Thu, 1 Feb 2018, SF Markus Elfring wrote:

> >> 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.
> >>
> >> Thus remove it from the first two SmPL rules and omit the rule "r4".
> >
> > Nack.
>
> I find such a rejection surprising once more.
>
>
> > It should be supported by the size determined in another way.
>
> I am curious on how our different views could be clarified further
> for this special software situation.
>
> * Do we agree that a proper size determination is essential for every
>   condition in the discussed SmPL rules together with forwarding
>   this information?

No.  I don't mind a few false positives.  The user can look at the answer
and see if it is a false positive or not.

Furthermore, I told you how to address this function so that the size
issue would be taken care of.  That is the patch that I would accept.

>
> * How can a name be ever relevant (within the published SmPL approach)
>   for a function when it was designed in the way that it should generally
>   work without a size parameter?

No idea what this means.

julia