Plaisirs et désillusions du monde moderne
My collaboration with OISF has been announced today. This is an honor for me to join this excellent team on this wonderful project. I’ve taken a lot of pleasure in the past months contributing to the project and I’m sure the start of an official collaboration will lead to good things. The challenge is high and I will do my best to merit the trust.
A big thanks to all people who congrat me for this nomination.
Suricata 1.1beta2 has brought OpenBSD to the list of supported operating system. I’m a total newbie to OpenBSD so excuse me for the lack of respect of OpenBSD standards and usages in this documentation.
Here’s the different step, I’ve used to finalize the port starting from a fresh install of OpenBSD.
If you want to use source taken from git, you will need to install building tools:
pkg_add git libtool
automake and autoconf need to be installed to. For a OpenBSD 4.8, one can run:
pkg_add autoconf-2.61p3 automake-1.10.3
For a OpenBSD 5.[01], one can run:
pkg_add autoconf-2.61p3 automake-1.10.3p3
For OpenBDS 5.2:
pkg_add autoconf-2.61p3 automake-1.10.3p6
Autoconf 2.61 is know to work, some other versions triggers a compilation failure.
Then you can simply clone the repository and run autogen:
git clone git://phalanx.openinfosecfoundation.org/oisf.git cd oisf export AUTOCONF_VERSION=2.61 export AUTOMAKE_VERSION=1.10 ./autogen.sh
Before running configure, you need to add the dependencies:
pkg_add gcc pcre libyaml libmagic libnet-1.1.2.1p0
Now, we’re almost done and we can run configure:
CPPFLAGS="-I/usr/local/include" CFLAGS="-L/usr/local/lib" ./configure --prefix=/opt/suricata
You can now run make and make install to build and install suricata.
Following my preceding post on suricata multithread performance I’ve decided to continue to work on the subject.
By using perf-tool, I found out that when the number of detect threads was increasing, more and more time was used in a spin lock. One of the possible explanation is that the default running mode for pcap file (RunModeFilePcapAuto) is not optimal. The only decode thread take some time to treat the packets and he is not fast enough to send data to the multiple detect threads. This is triggering a lot of wait and a CPU usage increase. Following a discussion with Victor Julien, I decide to give a try to an alternate run mode for working on pcap file, RunModeFilePcapAutoFp.
The architecture of this run mode is different. A thread is in charge of the reading of the file and the treatment of packets is done in a pool of threads (from decode to output). The augmentation of the power of decoding and the limitation of the ratio decode/detect would possibly bring some scalability.
The following graph is a comparison of the Auto mode and the FP mode on the test system described in the previous post (A 24 threads/core server parses a 6.1Go pcap file). It displays the number of packets per second in function of the number of threads:
The performance difference is really interesting. The FP mode shows a increase of the performance with the number of threads. This is far better than the Auto run mode where performance decrease with the number of threads.
As pointed out in a discussion on the OISF-users mailing list, multithread tuning has a real impact on performance. The result of the tests I’ve done are significant but they only apply to the parsing of a big pcap file. You will have to tune Suricata to see how to take the best of it on your system.
Suricata IDS/IPS architecture is heavily using multithreading. On almost every runmode (PCAP, PCAP file, NFQ, …) it is possible to setup the number of thread that are used for detection. This is the most CPU intensive task as it does the detection of alert by checking the packet on the signatures. The configuration of the number of threads is done by setting
a ratio which decide of the number of threads to be run by available CPUs (detect_thread_ratio variable).
A discussion with Florian Westphal at NFWS 2010 convince me that it was necessary for performance to tune with more granularity the thread and CPU link. I thus decide to improve this part of the code in Suricata and I’ve recently submitted a serie of patches that enable a fine setting.
I’ve been able to run some tests on a decent server:
processor : 23
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
This is a dual 6-core CPUs with hyperthreading activated and something like 12 Go of memory. From a Linux point of view, it has 24 identical processors.
I was not able to produce a decent testing environnement (read able to inject traffic) and all tests have been made on the parsing of a 6.1Go pcap file captured on a real network.
I’ve first tested my modification and soon arrive to the conclusion that limiting the number of threads was a good idea. Following Victor Julien suggestion, I’ve played with the detect_thread_ratio variable to see its influence on the performance. Here’s the graph of performance relatively to the ratio for the given server:
It seems that the 0.125 value (which correspond to 3 threads) is on this server the best value.
If we launch the test with ratio 0.125 more than one time, we can see that the performance vary between 64s and 50s with a mean of 59s. This means the variation is about 30% and the running can not be easily predicted.
It is now time to look at the results we can obtain by tuning the affinity. I’ve setup the following affinity configuration which run 3 threads on selected CPU (for our reader 3 = 0.125 * 24):
cpu_affinity:
- management_cpu_set:
cpu: [ 0 ] # include only these cpus in affinity settings
- receive_cpu_set:
cpu: [ 1 ] # include only these cpus in affinity settings
- decode_cpu_set:
cpu: [ "2" ]
mode: "balanced"
- stream_cpu_set:
cpu: [ "0-4" ]
- detect_cpu_set:
#cpu: [ 6, 7, 8 ]
cpu: [ 6, 8, 10 ]
#cpu: [ 6, 12, 18 ]
mode: "exclusive" # run detect threads in these cpus
threads: 3
prio:
low: [ "0-4" ]
medium: [ "5-23" ]
default: "medium"
- verdict_cpu_set:
cpu: [ 0 ]
prio:
default: "high"
- reject_cpu_set:
cpu: [ 0 ]
prio:
default: "low"
- output_cpu_set:
cpu: [ "0" ]
prio:
default: "medium"
and I’ve played with detect_cpu_set setting on the cpu variable. By using CPU set coherent with the hardware architecture, we manage to have result with a very small variation between run:
Thus we stabilize the best performance by remaining on the same hardware CPU and avoiding hyperthread CPUs. This also explain the difference between the run of the first tests. The only setting was the number of threads and we can encounter any of the setup (same or different hardware CPU, running two threads on a core with hyperthreading) or even flip during one test. That’s why performance vary a lot between tests run.
Next step for me will be to run perf tool on suricata to estimate where the bottleneck is. More infos to come !
I’m currently working on suricata and one of the feature I’m working on change the way the main structure Packet is accessed.
One of the consequences is that almost all unit tests need to be rewritten because the use Packet p construction which has to be replace by an dynamically allocated Packet *. Given the number of tests in suricata, this task is very dangerous:
I thus decide to give a try to coccinelle which is a "program matching and transformation engine which provides the language SmPL (Semantic Patch Language) for specifying desired matches and transformations in C code". Well, from user point of view it is a mega over-boosted sed for C.
One of the transformation I had to do was to find all memset() done on a Packet structure and replace it by a memset on the correct length followed by the setting of a pointer. In term of code with "..." meaning some code, I had to found all codes like
[C]func(...)
{
Packet p;
...
memset(&p, 0, ...);
}[/C]
and replace it by
[C]func(...)
{
Packet p;
...
memset(&p, 0, SIZE_OF_PACKET);
p->pkt = (uint8_t *)(p + 1);
}[/C]
To do so, I wrote the following semantic patch which defined the objects and the transformation I want to apply:
[diff]@rule0@
identifier p;
identifier func;
typedef uint8_t;
typedef Packet;
@@
func(...) {
<...
Packet p;
...
- memset(&p, 0, ...);
+ memset(&p, 0, SIZE_OF_PACKET);
+ p.pkt = (uint8_t *)(p + 1);
...>
}
[/diff]
If this semantic patch is saved in the file memset.cocci, you just have to run
spatch -sp_file packet.cocci -in_place detect.c
to modify the file.
The result of the command is that detect.c has been modified. Here's an extract of the resulting diff:
[diff]
@@ -9043,6 +9100,7 @@ static int SigTest...m_type() {
Packet p2;
memset(&p2, 0, SIZE_OF_PACKET);
+ p2.pkt = (uint8_t *)(p2 + 1);
DecodeEthernet(&th_v, &dtv, &p2, rawpkt2, sizeof(rawpkt2), NULL);
[/diff]
As you can see, spatch does not care that the variable is name p2. This is a Packet structure which is defined inside a function and which is memset() afterwards. It does the transformation knowing C and thus you need to think C when writing the semantic patch.
Now let's go for some explanations. The semantic patch start with the declaration of the parameters:
[diff]@rule0@ // name of the rule
identifier p; // this will be replace by the name of a variable
identifier func; // func will be the name of something
typedef uint8_t; // this is a C type we will use
typedef Packet; // same remark
@@
[/diff]
The main point is that, as coccinelle is using variable you must give in the information about what is a variable for you (usage of identifier) but you also need to specify what word are specific to the code (usage of typedef in the example).
The rest is straightforward if we omit an astuce I will detail:
[diff]func(...) { // the modification occurs in any function
<... // there is some code (...) who can occur more than once (<)
Packet p; // a variable is a Packet, we named it p
... // some code
- memset(&p, 0, ...); // a memset is done on p, we remove it (-)
+ memset(&p, 0, SIZE_OF_PACKET); // and replace it
+ p.pkt = (uint8_t *)(p + 1); // by this two lines (+)
...> // the part of the code occuring more than once end here
}
[/diff]
My complete semantic patch for the suricata modification is around 55 lines and the resulting patch on suricata has the following git stat:
30 files changed, 3868 insertions(+), 2745 deletions(-)
and a size of 407Ko. This gives an idea of the power of coccinelle.
Here's a light example of what coccinelle is able to do. If you want to read further just go on coccinelle website or read my "Coccinelle for the newbie" page.
I like to thanks Holger Eitzenberger for talking me about the existence of Coccinelle and I give out a great thanks at Julia Lawall for her expertise and her patience. She helps me a lot during my discovery of Coccinelle.
I have recently faced the challenge to rewrite a git repository. It has two problems:
I then dig into the doc and it leads me directly to ‘filter-branch’ which was the solution of my two problems. The names of the command is almost self-explanatory: it is used to rewrite branches.
A rapid reading of ‘git help filter-branch’ convince me to give a try to the ‘subdirectory-filter’ subcommand:
--subdirectory-filterOnly look at the history which touches the given subdirectory. The result will contain that directory (and only that) as its project root. Implies
--remap-to-ancestor
Thus to split the directory, I have simply to copy my repository via a clone call and run the filter command:
git clone project project-src cd project-src git filter-branch --subdirectory-filter src
Doing once again for the deps directory and I had my two new repositories ready to go.
At once during this cleaning task, I wanted to avoid to loose my directory structure. I mean I want to keep the ‘src’ directory in the ‘src’ repository. Thanks to the examples at the end of ‘git help filter-branch’, I’ve found this trickier command:
git filter-branch --prune-empty --index-filter \\ 'git rm -r --cached --ignore-unmatch deps' HEAD
This literally do the following : for each commit (--index-filter), suppress (rm) recursively (-r) all items of the ‘deps’ directory. If a commit is empty then suppress it from history (--prune-empty).
‘deps’ directory was known to take a lot of disk space and I thus done a check to see the size of the ‘src’ directory. My old friend ‘du’ sadly told me that the split repository has the same size as the whole one ! There is something tricky here. After googling a little bi I’ve found out (mainly by reading Luke Palmer post) that git never destroy immediately a commit. It is always present has an object in the .git/objects directory. To ask for an effective suppression, you’ve got to tell git that some objects are expired and can now be destroyed. The following command will destroy all objects unreachable since more than one day:
git gc --aggressive --prune=1day
Unreachable objects means objects that exist but that aren’t readable from any of the reference nodes. This last definition is taken from ‘git help fsck’. The ‘fsck’ command can be used to check the validity
and connectivity of objects in the database. For example to display unreachable object, you can run:
git fsck --unreachable
My problem on badly authored commits was still remaining. From the documentation, --env-filter subcommand was the one I need to use. The idea of the command is that it will iterate on every commit of the branch giving you some environnement variables:
GIT_COMMITTER_NAME=Eric Leblond GIT_AUTHOR_EMAIL=eleblond@example.com GIT_COMMIT=fbf7d74174bf4097fe5b0ec559426232c5f7b540 GIT_DIR=/home/regit/git/oisf/.git GIT_AUTHOR_DATE=1280686086 +0200 GIT_AUTHOR_NAME=Eric Leblond GIT_COMMITTER_EMAIL=eleblond@example.com GIT_INDEX_FILE=/home/regit/git/oisf/.git-rewrite/t/../index GIT_COMMITTER_DATE=1280686086 +0200 GIT_WORK_TREE=.
If you modify one of them and export the result, the commit will be modifed accordingly. For example, my problem was that commit
from ‘jdoe’ are in fact from ‘John Doe’ which mail is ‘john.doe@example.com’. I thus run the following command:
git filter-branch -f --env-filter '
if [ "${GIT_AUTHOR_NAME}" = "jdoe" ]; then
GIT_AUTHOR_EMAIL=john.doe@example.com;
GIT_AUTHOR_NAME="John Doe";
fi
export GIT_AUTHOR_NAME
export GIT_AUTHOR_EMAIL
'
Git show here once again it has been made by semi-god hackers that have developped it to solve their own source management problems.
Oui, bon, vous savez sans doute que le noyau Linux 2.6.30 est en cours de réalisation. Mais saviez-vous que grâce à l’excellent Denis Bodor toute une série de patchs a été incorporée au noyau ?
Lors de la rédaction du Hors Série Netfilter de GLMF, j’ai, avec tous les autres rédacteurs (Gwenael, Haypo, Pollux et Toady), voulu faire découvrir les dernières avancées de Netfilter. Et, forcément, lorsque l’on est sur le fil du rasoir et que l’on pousse les choses à fond pour être le plus précis possible, il arrive que l’on découvre des problèmes ou des choses pas aussi pratiques que on le désirerait.
J’ai donc réalisé une série de patchs pour améliorer l’expérience des lecteurs de ce splendide Hors Série Netfilter :
Merci donc à Denis pour nous avoir fait confiance pour ces articles et merci à Patrick McHardy d’avoir accepté mes patchs.
Non, non, vous ne verrez pas dans cet article de screenshots du noyau ! J’ai juste envie de poster ici une capture d’écrans que j’ai réalisée et commentée il y a quelque temps. J’étais à ce moment-là en train de réaliser un des mes développements noyau les plus conséquents et cela m’avait conduit à industrialiser mon environnement de travail pour effectuer développements et tests de la manière la plus efficace possible.
Voici donc la capture :
La résolution est assez élévée puisque mon bureau est constitué d’un écran 19” et d’un 22” placés côte à côte en mode twinview.
Le 22 pouces me permet d’utiliser confortablement un gvim ouvert sur 2 colonnes. Je peux ainsi éditer un fichier en lisant la documentation, ou bien comparer deux fichiers facilement. Sur le 19 pouces de gauche, j’ai fait tourner :
Je pouvais ainsi étudier les crashs ou les problèmes noyaux tout en lisant le code pour trouver mes erreurs.
Du côté de mes contributions au logiciel libre, l’année 2009 commence assez fort. Il semble que j’ai réussi à déclencher une petite révolution.
Le système de test de NuFW avait mis en évidence un crash rare, non reproductible facilement dans nuauth, le serveur d’authentification de NuFW. Les sorties de gdb ou valgrind révélaient un problème absurde dans la bibliothèque cyrus-sasl. NuFW l’utilise pour réaliser la phase d’authentification des utilisateurs. Le crash apparaissait lors d’un appel à sasl_dispose() qui est la fonction à appeler lorsque l’on a terminé la phase d’authentification. Après maintes vérifications et plusieurs dizaines d’heures de debug, j’étais convaincu que nuauth, le serveur d’authentification de NuFW, utilisait la bibliothèque de manière correcte et que le code environnant était correct.
Lorsque l’utilisation d’une bibliothèque est légitime et que l’on obtient un plantage, c’est que l’on a trouvé un bug. J’ai donc alors commencé à enquêter sur Cyrus-sasl. Cette bibliothèque est développée dans le cadre du projet cyrus (serveur de mail imap) par la Carnegie Mellon University. Elle est utilisée par un nombre conséquent de logiciels libres fameux (dont openldap, sendmail). Même si sendmail a une réputation sulfureuse de sécurité, il est connu pour sa stabilité. Et donc, en me lançant dans le debug de ce problème début septembre 2008, je savais que je m’attaquais à quelque chose de robuste car très utilisé. Le bug allait donc être complexe à trouver.
J’enchainais alors des séances de deboguage plus ou moins longues passant à certain moment plusieurs longues journées de travail (lire 14 ou 15 heures) sur ce problème. Je sortais tout de même victorieux de la confrontation et le 20 septembre 2008, j’envoyais un message à la liste de diffusion cyrus-sasl : [PATCH] Fix problem with sasl_set_mutex
NuFW utilise les bibliothèques cyrus-sasl et libldap_r et libldap_r utilise lui aussi cyrus-sasl. Elle s’en sert lors de la phase d’authentification sur la base LDAP. Comme, et libldap_r et NuFW sont multithreadés ou multithreadable, ils initient tous les deux la bibliothèque cyrus-sasl pour le support des threads. Il y a notamment un appel à sasl_set_mutex() qui définit l’implémentation de mutex à utiliser. NuFW appelle cette fonction avec ses propres paramètres et libldap_r fait de même (même lorsque l’on fait un bind simple, les connaisseurs apprécieront). Or sasl_set_mutex() ne détectait pas qu’une initilisation avait déjà été faite. On avait donc un conflit possible. Les fonctions de mutex sasl prennent des paramètres void* en entrée et travaille sur ces pointeurs. Il y donc potentiellement des casts dangereux.
Dans le cas de NuFW, le problème était beaucoup plus radical. L’initialisation de libldap_r se fait lors du chargement du module ldap de nuauth. Par conséquent, c’est la fonction ldap qui est utilisée après chargement du module. Or, nuauth peut changer de configuration et donc de modules à chaud. Il réalise notamment un déchargement des modules. Or, cela ne met pas à jour la fonction mutex de sasl qui appelle donc une fonction déchargée. Ceci conduit immanquablement au crash. Cette fonctionnalité de modification de configuration à chaud est massivement utilisé dans le système de tests de NuFW et c’est donc pour cette raison que le crash ne se produisait qu’à cet endroit.
J’aurais du déboguer plus rapidement ce problème. La piste que j’aurais du voir plus tôt était l’utilisation de fonctions stockées à des emplacements mémoires non valides. Cette information était donnée par gdb et j’aurais du lui faire d’avantage confiance.
Ma remontée de bug et mon patch ont rapidement été pris au sérieux et un patch implémentant mon idée a été commité dans les sources : Fixed sasl_set_mutex() to disallow changing mutex management functions once sasl_server_init/sasl_client_init is called
J’étais content de voir ce correctif appliqué, mais vu la criticité pour NuFW, j’aurais été satisfait de voir arriver une nouvelle version de cyrus-sasl fixant ce bug. Le problème étant déclenché par une utilisation précise de la bibliothèque, je n’étais pas en droit de remonter mon exigence. De plus, la dernière version de cyrus-sasl date du 19 mai 2006 et je me doutais donc que je n’allais pas être entendu.
Début janvier, un mail envoyé sur la liste a pointé le fait que le bug était reproductible en utilisant le stockage des mots de passe sasl dans ldap : En utilisant lui aussi la bibliothèque libldap_r cyrus-sasl se mordait la queue. Le bug était donc aussi interne à cyrus-sasl. Fort de cette conclusion, j’envoyais une réponse au message signalant le problème :
This made the bug self contained and not dependant of other applications. Given the fact that the effect of this bug is a crash of the calling program, it could be interesting to release a new version of the sasl library. (my 0.02$)
J’avais ainsi osé demandé une nouvelle version sur un logiciel où je n’avais pas écrit une ligne de code. À ma surprise, cela s’est conclu par ce message : Next release of CMU SASL – call for favorite bugfixes où un membre de l’équipe de développement annonce l’arrivée probable, aux alentours du 15 février, d’une nouvelle version de la bibliothèque et demande quels sont les corrections de bugs que les utilisateurs voudraient voir figurer dans cette version.
Je commence donc l’année 2009, en réussissant à déclencher la sortie d’une nouvelle version d’une bibliothèque qui n’avait pas eu de nouvelles versions depuis près de trois ans !
Je conclus ce poste en plagiant pollux et en revoyant mes objectifs de contributions à la hausse pour l’an prochain :
En 2010, je déclenche une sortie de Debian.
La journée utilisateurs du Netfilter Workshop aura lieu à Paris le 29 septembre 2008. Cette journée prendra la forme d’une série de conférences sur Netfilter. Les sujets seront variés allant de la description de l’utilisation de Netfilter chez un ISP dannois à la présentation par David Miller (maiteneur de la couche réseau de Linux) ou Patrick McHardy (Leader du projet Netfilter) de leurs derniers développements.
Je donnerai d’ailleurs lors de cette journée une conférence sur ulogd2, la nouvelle infrastructure de journalisation de Netfilter.
L’événement aura lieu dans les locaux de l’ESIEA dans le 13ème arrondissement de Paris. L’accès est libre et une inscription est demandée.