* Coccinelle Timeline
@ 2016-10-17 2:05 Elizabeth Ferdman
0 siblings, 0 replies; only message in thread
From: Elizabeth Ferdman @ 2016-10-17 2:05 UTC (permalink / raw)
To: julia.lawall; +Cc: outreachy-kernel
Hey Julia,
One of my ideas is to do some outreach for constification, and/or
constification using coccinelle, such as a how-to article/blog post.
This could make it easier for people to understand when and why
structures need to be const and when they shouldn't be, and providing
easy spatch scripts and commands could get people started quickly, even
if they don't know coccinelle that well yet. A lot of people are already
using coccinelle, so they could easily do constification.
Document the process of constification more thoroughly. For example, I
noticed that sometimes structures would be passed to a register or
deregister function and that was a sign that they would be altered.
Document cases like these as "When not to Constify".
Write better coccinelle scripts to eliminate these cases if possible.
For example, Bhumika helped me out by giving me this script to catch all
static structs that didn't have const:
@r disable optional_qualifier@
identifier s,i;
@@
* static struct s i ={...};
That's a lot of cases. So maybe write scripts that
eliminated cases in which i's members are being modified in the same
file. So I wouldn't want anything that looks like this in the file: i.x
Month 1:
Learn more about whether or not to constify. Document these cases and
send in patches when constification is appropriate.
Develop spatches that can eliminate false positives that were
documented-- hard part.
Publish articles like "Constification using Coccinelle" explaining why,
when, how.
Can helper scripts (bash) be created to facilitate the process, similar
to Small Task 2?
Learn more about what it means for code to be modifiable at runtime.
Constification of which structures is actually helping to secure the
kernel? Where is it highest priority? How do these attacks work?
Are we working on code that is built in to the kernel, modules, or both?
Month 2:
Learn about __ro_after_init, and what initialization in several steps
looks like. How to identify these cases? How to use coccinelle to
identify them? When does __init need to be added?
Document those cases, send in patches, publish findings.
Month 3:
Reflect on progress and think about what further steps need to be taken.
After adding const, __ro_after_init, and __init, is the problem solved?
What other security risks can Coccinelle address besides
constification?
Thanks,
Liz
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-10-17 2:05 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-17 2:05 Coccinelle Timeline Elizabeth Ferdman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.