1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
In the topic of *code analysis* or *program analysis* ([[!wikipedia
Program_analysis_(computer_science) desc="Wikipedia article"]]), there is
static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia
article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis
desc="Wikipedia article"]]). This topic overlaps with [[performance
analysis|performance]], [[formal_verification]], as well as general
[[debugging]].
[[!toc]]
# Bounty
There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.
# Static
* [[GCC]]'s warnings. Yes, really.
* GCC plugins can be used for additional semantic analysis. For example,
<http://lwn.net/Articles/457543/>, and search for *kernel context* in
the comments.
* Have GCC make use of [[RPC]]/[[microkernel/mach/MIG]] *in*/*out*
specifiers, and have it emit useful warnings in case these are pointing
to uninitialized data (for *in* only).
* [[Port Sequence Numbers|microkernel/mach/ipc/sequence_numbering]]. If
these are used, care must be taken to update them reliably, [[!message-id
"1123688017.3905.22.camel@buko.sinrega.org"]]. This could be checked by a
static analysis tool.
* [Static Source Code Analysis Tools for C](http://spinroot.com/static/)
* [[!wikipedia List_of_tools_for_static_code_analysis]]
* [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/)
For example, [Debian's hurd_20110319-2
package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html)
(Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious;
the realloc issues are for real*).
* Coccinelle
* <http://lwn.net/Articles/315686/>
* <http://www.google.com/search?q=coccinelle+analysis>
* clang
* <http://www.google.com/search?q=clang+analysis>
* Linux' sparse
* <https://sparse.wiki.kernel.org/>
* <http://klee.llvm.org/>
* <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html>
* [Smatch](http://smatch.sourceforge.net/)
* [Parfait](http://labs.oracle.com/projects/parfait/)
* <http://lwn.net/Articles/344003/>
* [Saturn](http://saturn.stanford.edu/)
* [Flawfinder](http://www.dwheeler.com/flawfinder/)
* [sixgill](http://sixgill.org/)
* [Coverity](http://www.coverity.com/) (nonfree?)
# Dynamic
* [[community/gsoc/project_ideas/Valgrind]]
* <http://en.wikipedia.org/wiki/Electric_Fence>
* <http://sourceforge.net/projects/duma/>
* <http://wiki.debian.org/Hardening>
* <https://wiki.ubuntu.com/CompilerFlags>
* IRC, freenode, #glibc, 2011-09-28
<vsrinivas> two things you can do -- there is an environment variable
(DEBUG_MALLOC_ iirc?) that can be set to 2 to make ptmalloc (glibc's
allocator) more forceful and verbose wrt error checking
<vsrinivas> another is to grab a copy of Tor's source tree and copy out
OpenBSD's allocator (its a clearly-identifyable file in the tree);
LD_PRELOAD it or link it into your app, it is even more aggressive
about detecting memory misuse.
<vsrinivas> third, Red hat has a gdb python plugin that can instrument
glibc's heap structure. its kinda handy, might help?
<vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry.
* In context of [[!message-id
"1341350006-2499-1-git-send-email-rbraun@sceen.net"]]/the `alloca` issue
mentioned in [[gnumach_page_cache_policy]]:
IRC, freenode, #hurd, 2012-07-08:
<youpi> braunr: there's actually already an ifdef REDZONE in libthreads
It's `RED_ZONE`.
<youpi> except it seems clumsy :)
<youpi> ah, no, the libthreads code properly sets the guard, just for
grow-up stacks
* Input fuzzing
Not a new topic; has been used (and a paper published) for early UNIX
tools, I[[I|tschwinge]]RC.
* <http://caca.zoy.org/wiki/zzuf>
What about some [[RPC]] fuzzing?
|
