From: Emese Revfy <re.emese@gmail.com>
To: Kees Cook <kees.cook@canonical.com>
Cc: Lionel Debroux <lionel_debroux@yahoo.fr>,
linux-kernel@vger.kernel.org,
Brad Spengler <spender@grsecurity.net>
Subject: Re: status of constification
Date: Tue, 09 Nov 2010 22:54:08 +0100 [thread overview]
Message-ID: <4CD9C300.6040405@gmail.com> (raw)
In-Reply-To: <20101108223844.GS5876@outflux.net>
On 11/08/10 23:38, Kees Cook wrote:
> Hi,
>
> So, I'm trying to come up to speed on what's still outstanding in the
> effort to constify function pointers. I saw patches from Emese Revfy
> go in, and I saw Lionel Debroux's recent patches. What already-created
> work still needs attention? I know there's more code to be written,
> but I'm trying to find any patches that have already been written but
> have not gone upstream yet.
Hi,
I will gladly break up my current patch for the next -rc by structure
type or maintainer (some preferred it one way or the other) and send
it in some time next week so that you can handle the upstream submission
process (I will continue to maintain my patch in grsecurity).
There are many structures that can be constified, you can use the following
command to find most of them (use it on an allyesconfig kernel preferably):
grep _ops System.map |grep -Ewi 'b|d' | awk '{print $3}' | \
while read i ; do cscope -d -L -1 $i | grep -E "struct[ \t]*([^ ]*)[ \t]*" \
--color=none -o | awk '{print $2}' ; done |sort -u
Also there are always new instances of structures going in that should have
been constified.
I tried to automate the whole process with Coccinelle but I abandoned it
because Coccinelle didn't support recursive header file inclusion at the time.
If someone feels like fixing Coccinelle then I would quickly finish my script
(it has a few bugs because I could never test it for real), but see the end
of the mail for the current version. I think it would be a good idea because
it would take a few hours only to generate a constification patch for a new
kernel. One thing that probably cannot be automated with Coccinelle is that
once the script determines that a given structure cannot be constified, it
cannot undo already emitted patches for the given structure so it must be
cleaned up by post processing script.
--
Emese
// spatch.opt -sp_file $1 -include_headers -local_includes -all_includes -I "include/" -dir $2
@initialize:python@
noconst = []
@stc@
identifier idtype, y;
type t;
position p;
@@
struct idtype {
...
t (*y)(...);@p
...
};
@notjustfp@
identifier stc.idtype, y;
type t;
position p != stc.p;
@@
struct idtype {
...
t y;@p
...
};
@script:python depends on notjustfp@
@@
cocci.include_match(False)
@variable@
identifier stc.idtype, idvariant, id;
@@
(
struct idtype idvariant = {
...
};
|
struct idtype idvariant;
|
struct idtype *idvariant;
|
struct id {
...
struct idtype idvariant;
...
};
)
@script:python@
y << variable.idvariant;
@@
if y in noconst:
cocci.include_match(False)
@alreadyconst@
identifier stc.idtype, variable.idvariant, id;
@@
(
const struct idtype idvariant;
|
const struct idtype idvariant = {
...
};
|
const struct idtype *idvariant;
|
struct id {
...
const struct idtype idvariant;
...
};
)
@script:python depends on alreadyconst@
@@
cocci.include_match(False)
@fn_declaration@
identifier stc.idtype, variable.idvariant, fn;
type t;
@@
t fn(struct idtype *idvariant);
@fn_definition@
identifier stc.idtype, variable.idvariant, fn;
type t;
@@
t fn(struct idtype *idvariant)
{
...
}
// TODO: handle var.field1.field2, var->field1->field2
@assignement@
identifier variable.idvariant, x, idptr;
@@
(
idvariant.x = ...;
|
idvariant->x = ...;
|
idptr = &idvariant;
...
idptr->x = ...;
|
memcpy(&idvariant, ...);
|
memcpy(idvariant.x, ...);
|
memcpy(idvariant->x, ...);
|
idvariant = kzalloc(...);
|
idvariant = kmalloc(...);
)
@script:python depends on assignement@
x << stc.idtype;
y << variable.idvariant;
@@
print "Cannot be const: %s-%s" % (x, y)
noconst.append(y)
cocci.include_match(False)
@depends on stc && !fn_declaration && !fn_definition@
identifier stc.idtype, variable.idvariant, id;
@@
(
-struct idtype idvariant = {
+const struct idtype idvariant = {
...
};
|
-struct idtype idvariant;
+const struct idtype idvariant;
|
-struct idtype *idvariant;
+const struct idtype *idvariant;
|
-struct idtype *idvariant = NULL;
+const struct idtype *idvariant = NULL;
|
struct id {
...
-struct idtype idvariant;
+const struct idtype idvariant;
...
};
)
@depends on stc && fn_declaration && !fn_definition@
identifier stc.idtype, variable.idvariant, fn_declaration.fn;
type fn_declaration.t;
@@
t fn(
-struct idtype *idvariant
+const struct idtype *idvariant
);
@depends on stc && !fn_declaration && fn_definition@
identifier stc.idtype, variable.idvariant, fn_definition.fn;
type fn_definition.t;
@@
t fn(
-struct idtype *idvariant
+const struct idtype *idvariant
)
{
...
}
next prev parent reply other threads:[~2010-11-09 21:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-08 22:38 status of constification Kees Cook
2010-11-09 21:54 ` Emese Revfy [this message]
[not found] ` <4CD9BF25.4090306@gmail.com>
2010-11-10 6:35 ` [Cocci] " Julia Lawall
2010-11-11 21:48 ` Emese Revfy
2010-11-11 22:53 ` Julia Lawall
2010-11-13 12:13 ` Emese Revfy
2010-11-13 13:43 ` Julia Lawall
2010-11-13 14:41 ` Julia Lawall
2011-05-28 3:13 ` Kees Cook
2011-05-28 6:39 ` [Cocci] " Julia Lawall
2011-06-05 21:47 ` Emese Revfy
2011-06-06 5:03 ` Julia Lawall
2011-06-06 7:49 ` Julia Lawall
2011-06-10 21:28 ` Emese Revfy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CD9C300.6040405@gmail.com \
--to=re.emese@gmail.com \
--cc=kees.cook@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lionel_debroux@yahoo.fr \
--cc=spender@grsecurity.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox