All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elizabeth Ferdman <gnudevliz@gmail.com>
To: julia.lawall@lip6.fr
Cc: outreachy-kernel@googlegroups.com
Subject: Coccinelle Timeline
Date: Sun, 16 Oct 2016 19:05:19 -0700	[thread overview]
Message-ID: <20161017020518.GA6836@localhost> (raw)

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


                 reply	other threads:[~2016-10-17  2:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20161017020518.GA6836@localhost \
    --to=gnudevliz@gmail.com \
    --cc=julia.lawall@lip6.fr \
    --cc=outreachy-kernel@googlegroups.com \
    /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 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.