Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1597408ybg; Thu, 4 Jun 2020 14:00:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkWZOA2q6GLmzBqlAYsxbiADo+DteIkKYazccWa79t9zVGpCFQvRLAkobKJWwOUidkRbEt X-Received: by 2002:a17:906:3843:: with SMTP id w3mr5789438ejc.177.1591304455833; Thu, 04 Jun 2020 14:00:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591304455; cv=none; d=google.com; s=arc-20160816; b=wTW9p9tnjhY+ePUOr5WFZPfgu/0kw9T8gnAU03ECsrDNOcHJadnaMe7LivWhTuLo9m 41G8qQ2U/Lado5eB5FidMxHoEy5qM2BihPJ6CI/n4cgWtBKSb5tIK2X3/esEwyVUU0aM cpstP38fWBJnS1icOYHR1/0FKvl7BMxPZakGnNMyzLLPE8PBq/ZI8OzTk64qUnN6BHf6 JBTQ+P+sO1AA7LSDankq5ULVr/gDkMD5SyZgtKl/Tm4O2D2btg3qSDeMXztk1tU8k4T+ Jn9Vw4nBmoWS25WApwzhMe/YpIn6P3L/DjB5DCPfPyiSycFPnXpWJKUJHxuTBCgAtPAE kfrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=QG5UHM/EV5by7lFSo/9y7vsgGlDUP34mLVxZeplZha8=; b=N7wAxxjDHxl8C56WGBTCrWkIXiTJCJn8HGaF6Qz6CigCZqchi0VIIYg9jTTkEqT89Z LRGGvPlGwqAeojpP3K6zaRId+47eeebZGcnpHUfm2XiuR96avpuIXMN5FId1+ECTJZRb 2dtbkerUqjIP85m+twK8EhXkQa9CvN0lm5Xvx03e2KP2piCS3VNnNVzDwt7L42pdydX8 XES/o+L3xh0W5nzlbHBeWl2XZ/Td/Hqla4BsRL4yWdcRWWX7eV8GsoqvkpPBi6ECkuuv REW5OdKSugw5NEOfy9/C9Aox//JxS5QzUybSMs4qKExK+hzck+vA9Mf62lr/8WZFc6kj MakA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q16si2187527eju.407.2020.06.04.14.00.32; Thu, 04 Jun 2020 14:00:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729959AbgFDU57 (ORCPT + 99 others); Thu, 4 Jun 2020 16:57:59 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:18801 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729848AbgFDU5r (ORCPT ); Thu, 4 Jun 2020 16:57:47 -0400 X-IronPort-AV: E=Sophos;i="5.73,472,1583190000"; d="scan'208";a="350629662" Received: from abo-173-121-68.mrs.modulonet.fr (HELO hadrien) ([85.68.121.173]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2020 22:57:18 +0200 Date: Thu, 4 Jun 2020 22:57:18 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Denis Efremov cc: Joe Perches , cocci@systeme.lip6.fr, linux-kernel@vger.kernel.org Subject: Re: [Cocci] [PATCH v2] coccinelle: api: add kzfree script In-Reply-To: <20200604204846.15897-1-efremov@linux.com> Message-ID: References: <20200604140805.111613-1-efremov@linux.com> <20200604204846.15897-1-efremov@linux.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 4 Jun 2020, Denis Efremov wrote: > Check for memset()/memset_explicit() with 0 followed by > kfree()/vfree()/kvfree(). > > Signed-off-by: Denis Efremov > --- > Changes in v2: > - memset_explicit() added > - kvfree_sensitive() added > - forall added to r1 > - ... between memset and kfree added > Unfortunately, it doesn't work as I would expect it to in "patch" > mode. I've added my comment about it in the rule. It can be safely > removed from the patch if I misunderstood something. > > Another "strange" behaviour that I faced that r2 rule works only if I > write 2 expression lines: > expression *E; > expression size; > If I try to use a single line "expression *E, size;" then r2 matches nothing. The parser for metavariables is not so smart. Everything to the left of the first metavariable name is the type. Everything after is the list of metavariables of that type. So if you put them together you require size to be a pointer. On the other hand, do you really require E to be a pointer? If you do that, it will have to find the type of E. If E refers to a structure field, then the type might not be available in the current function, and you may need command line argments like --all-includes or --recursive-includes. Is avoiding transforming the case where E is not verified to be a pointer a concern? julia > > scripts/coccinelle/api/kzfree.cocci | 65 +++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > create mode 100644 scripts/coccinelle/api/kzfree.cocci > > diff --git a/scripts/coccinelle/api/kzfree.cocci b/scripts/coccinelle/api/kzfree.cocci > new file mode 100644 > index 000000000000..5c7e4bb13bb7 > --- /dev/null > +++ b/scripts/coccinelle/api/kzfree.cocci > @@ -0,0 +1,65 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/// > +/// Use kzfree, kvfree_sensitive rather than memset or > +/// memset_explicit with 0 followed by kfree > +/// > +// Confidence: High > +// Copyright: (C) 2020 Denis Efremov ISPRAS > +// Options: --no-includes --include-headers > +// > +// Keywords: kzfree, kvfree_sensitive > +// > + > +virtual context > +virtual patch > +virtual org > +virtual report > + > + > +// Ignore kzfree definition > +// Ignore kasan test > +@r depends on !patch && !(file in "lib/test_kasan.c") && !(file in "mm/slab_common.c") forall@ > +expression *E; > +position p; > +@@ > + > +* \(memset\|memset_explicit\)(E, 0, ...); > + ... when != E > + when strict > +* \(kfree\|vfree\|kvfree\)(E)@p; > + > +@r1 depends on patch && !(file in "lib/test_kasan.c") && !(file in "mm/slab_common.c")@ > +expression *E; > +expression size; > +@@ > + > +- \(memset\|memset_explicit\)(E, 0, size); > +/// Unfortunately, it doesn't work as in !patch mode. > +/// spatch (v1.0.8) should patch 4 functions in linux 5.7 with this rule > +/// and uncommented "when" lines. With only "... when != E" line 2 functions > +/// are patched, none with "when strict". 3 functions patch is produced by the > +/// rule with "when" lines commented out. > +// ... when != E > +// when strict > +( > +- kfree(E); > ++ kzfree(E); > +| > +- vfree(E); > ++ kvfree_sensitive(E, size); > +| > +- kvfree(E); > ++ kvfree_sensitive(E, size); > +) > + > +@script:python depends on report@ > +p << r.p; > +@@ > + > +coccilib.report.print_report(p[0], "WARNING opportunity for kzfree/kvfree_sensitive") > + > +@script:python depends on org@ > +p << r.p; > +@@ > + > +coccilib.org.print_todo(p[0], "WARNING opportunity for kzfree/kvfree_sensitive") > -- > 2.26.2 > > _______________________________________________ > Cocci mailing list > Cocci@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci >