Pierre Schweitzer’s Blog

In order to catch any regression in ReactOS, but also to develop ReactOS using test-driven development method, ReactOS devs were using two testbots. One was running all the tests in a ReactOS virtual machine run by KVM under Linux, while the second one was running them in a ReactOS virtual machine run by Virtual Box under Windows.

The fact is that, under Linux, to achieve such work, we are using an application developed internally named sysreg2. This one, uses the libvirt API to create a KVM domain, to start it, and to check the serial output of the VM, to get the results of the tests run in ReactOS.

We recently decided that another testbot could be handy. It has been decided that as a first step, using VMware Player under Linux would provide interesting results. In order to keep the behavior of the testbots unified, sysreg2 was to be adapted to also manage this VM.

Fortunately, libvirt also provides a compatibility layer with VMware Player. The API is still the same, so, normally, it would not have required that many efforts to get the switch, as long as, the good connection address is provided for libvirt to the hypervisor: vmwareplayer:///session, in our case. Then, internally, libvirt simply convert its XML domains to VMX domains and uses VMware tools: vmplayer and vmrun.

But actually, it did not work that easily. First, VMware Player tools were silently failing at startup. A simple strace shown that the tools were trying to load several X11 libraries. And when those had been installed, the tools were lacking a DISPLAY. Installing a complete X11 server and client just for VMware would have been kind of overkill method.

The solution used has been to make usage of two bootstrap scripts for VMware tools and of XVFB. XVFB is an X virtual frame buffer. So that, the applications run within this VFB just think and act as if they had a display, whereas they actually do not really have. So, once installed, the bootstrap scripts were basically just issuing a xvfb-run of the VMware tool with its args.

Expect for vmrun. Two other issues raised. First, it needed a complete X11 install along with GTK to be able to display the VM window. The solution here has been to append, at the end of the run command the “nogui” instruction. So that vmrun does not try to display anything. The bootstrap script was modified that way, as we cannot really manage the libvirt commands issued to those tools. The other issues also came from libvirt commands. When libvirt tries to destroy a domain, it asks VMware to do a “soft” shutdown of the machine. In case (and it happens with ReactOS…) where the machine is totally locked, this is pointless. There, the bootstrap script has been modified again to force to “hard” any shutdown instruction it was receiving before passing to the real tool.

Also, VMware and KVM do not exactly support same kind of hardware, especially for serial devices. So, it has required rethink and rework about the way sysreg2 and VMware can communicate. Finally, the adopted solution was to make sysreg2 create an Unix socket so that virtual machine can connect on it and write (also read).

We got a testbot working successfully :-).

(more…)

During my studies at the ISIMA, I have been quickly presented MDE (Model Driven Engineering). We went through AOP (Aspect Oriented Programming), which is somehow a superset of OOP (Object Oriented Programming). With your objects, you can describe aspects and this will help you write simpler code, and more easily maintenable code. It also allows cutting in a clear way the application into modules. Some modules being generated during the complete build of the project.

So, with AOP, you can define points (known as pointcuts) in code where you will add other code, developed in parallel, responding to an aspect. This allow to do transerval checks or treatment to the application. Needless to say that it is really useful for applications security and stability. This is where the idea of code profiling is born.

It is possible with AOP to define pointcuts at the begin of a function execution and at the end of its execution. So, if you are able to match any function, it is virtually possible to add a pointcut to any function begin and end. Furthermore, once you know when a function starts and ends you can calculate how much time it needs.

This is what I do in my simple (for the moment?) framework. It just consists in an header for AspectC++ that will define two pointcuts: one before the begin of the execution of any function (be it a function for a class, an operator, or whatever) and at the end of the execution. Then, using the Linux system call time, it will get the time at which those operations occurs to gather data. The time resolution is low for the moment, the only purpose being to validate the concept. Once it is done with the execution of the function, it will store all the data into a structure remembering number of calls and total length for all the calls. This does not provide that many information for the moment, but it has proven to be working.

The strength of such approach is that it makes the whole code generic. There is no need to modify the code that has to be profiled to get it profiled. It just need to be parsed with the profiling header and then compiled. The code itself for profiling is pretty simple for the moment (as its output).

An example of execution works as following:

$ ./main
You want number of primes lower than? 999999
Result: 78498
Function: int main(int,char **), calls: 1, total time: 6
Function: unsigned int FrequencyOfPrimes(unsigned int), calls: 1, total time: 3

This is still work in progress for the moment, and the idea would be to get more features like better timer resolution, real support for recursive calls. But it keeps being a good beginning to show what are the features offered by the AOP.

You’ll be able to find the example code on GitHub.com.

On the 6th of June 2012, the Internet Society has decided to start an important and world wide event: the IPv6 Launch. This means that on this days, several Internet actors (website editors, network operators, hardware ventors) will make what they own IPv6 compatible (in a transparent way!). And will ensure it will stay that way. This is not the IPv6 day.

Regarding Internet then, this is a major event. And an agreement to get IPv6 launch is a great decision. This is why we [The ReactOS Foundation] decided to associate our name to this event. This means that several of the ReactOS servers will be compatible with IPv6 (not the OS itself!). A lot of work will have to be done (even if it was already done partly previously) to ensure everything gets ready on the 6th of June. A kind of roadmap is available here: IPv6.

This actually requires work. Not only to update configurations (this could be the easier part…). The real problems come from software that don’t support IPv6 properly and that need a rewrite or even worse a full rewrite. This is what I will be working on up to the 6th of June to get everything fully functional.

As an example, in order to “help” DenyHosts (which doesn’t handle IPv6 even with custom regexp), a new tool has been developed to run nearby it. It will catch all the non-allowed connections from an IPv6 address to SSH and will drop the IP in /etc/hosts.deny. All the tools that may be developed will be dropped at GitHub under GPL licence (ForbidHostsv6 is already there, follow the link). To permit everyone to make use of them, in case they also need them for the switch.

Let’s share our knowledge about that switch, to make it as easier as possible (and the smoother possible as well!).

It’s been a long time since the last blog update. One of the reasons for such an absence was that I was really busy at CERN. During my internship there (at LHCb experiment), my mission was to improve the way their diskless farm is working.

It was previously relying on the Red Hat diskless tools to allow ~15 nodes to run without disk, gathering their OS & their data from another server. But, this system and its implementation by Red Hat is really limited. Furthermore, starting with RHEL6 (Red Hat Enterprise Linux 6), the support for those tools has been dropped. The LHCb was to switch to another method.

One of the solution that was immediately looked at is file systems union. File systems union allow merging several directories (called branches) into one, in a transparent way. Some of those directories can be in read-only mode. Then, changes will only be applied to the writeable directories. So, for LHCb, the underlying idea was to use file systems union to provide easily manageable nodes. One shared root file system would be managed, and then snapshots (one per node) would be merged with shared root into different directories (one per node). And then nodes would boot on their directory. That was, you have each node with its personality and own file system easily. Without the constraints of the Red Hat tools.

We evaluated several file systems union drivers to select the one that was fitting our needs the best. Unfortunately, if several weren’t that easy to deploy, they were even worse to use. They were designed for totally different use (like, for example, LiveCD).

This is why, during a weekend, I designed a new union file system that would match their needs. As I was more creative for concepts than for names, I temporarily called it “PierreFS”. Feel free to find another one. If this file system takes most of its concept from the legacy UnionFS file system, it adds more features that are designed to highly reduce useless/redundant copyups (ie, files that were copied from read-only branch to read-write one, to be editable). One of the major feature of the PierreFS file system is its ability to split data & metadata when performing a copyup. It can handle both separately, to prevent data redundancy and allow easy updates of data, while metadata are modified. It has also a feature that permits the deletion of some copyups when it detected their are useless. Finally, this file system comes with some limitations since it’s targeting specific configurations. It can only merge one read-only & one writeable branches.

All the features described upper (including those from UnionFS) were implemented as a FUSE file system, to test viability of the file system and to validate the concepts. Unfortunately, this doesn’t include all the thought features. Some more like caching were first considered (and are still not dropped yet). The driver successfully passed our tests, and met LHCb expectations.

I’ve started portage to the Linux kernel as a driver for CERN. I hope I’ll be able to release it quickly. This work is once again based on UnionFS team work. This is a good basis to learn and understand.

You can find the FUSE driver at sourceforge.net (no packaging has been done - won’t be done).

This file system has been presented during the ICALEPCS11 conference at Grenoble, and has been described in the WEMMU05 paper & poster (with a comparison with the other file systems). All the conference material will be available on the conference site.

Indeed, now 2010 is over, it may be interesting to go back to it. Not for the same reasons that led the ReactOS to go back to 2010 (cf: r50529, a revert needed due to a bug on boot image handling). In fact, it is interesting to go back to 2010, just to see what has been done, what was planned, what has failed. Finally, what we can say and remember about that year.

First of all, I would like to speak about my servers. As you may know (or not) I currently own two servers, known as www.heisspiter.net and www2.heisspiter.net, and I also rent a third server at OVH, called www3.heisspiter.net. I was not speaking about them, because I was not really taking care of them. And this led to many and important issues (bad performances, bots, and so on). During a weekend, I decided to switch www3 to ipv6, which finally worked. But, it made me understand that my servers needed love, somehow. So, now, I am working back on them. The idea that they have reached some maturity point and can work alone is definitely wrong.  Indeed, 2009 was already a pretty bad year for heisspiter.net and 2010 was terrible. No evolution, several issues, servers down, … A quick look at statistics show that people also stop coming on the server. And I cannot blame them. 2010 was a really bad year for heisspiter.net, and 2011 cannot be worse. I will just do my best not to make it the same.
An encouraging note regarding heisspiter.net, at least. Some evolutions have started. I was talking about ipv6, but also a webmail for users arrived, upload service is back, mail server has been fixed, servers software have been updated, and heisspiter.net internal tools fixed. This actually explains why heisspiter.net is more stable since December!

Other major point… Of course, ReactOS! You may have seen, reading my other posts that the project did important step into stability and features. Some rewrites, some parts becoming more mature. MM rewrite, with Heap rewrite (for user-mode land) force developers to fix the ReactOS code to corrupt less memory (or to less corrupt memory?). And this works. Especially when fixes are applied to those rewrites. This also comes after some hard year for ReactOS, with no releases, and nothing to release, due to broken trunk. But, here, it is past!
My modest goal, for 2011, is to prove that ReactOS has gained some maturity now. Some testers are already pushing to get 0.4, and I would like to show we are not that far. And I will try to show it on my domain of work on ReactOS, ie filesystems and kernel. With the help of Johannes Anderwald, and Art Yerkes, I attempt to make ReactOS boot from Microsoft FastFAT driver. Johannes has brought some code for tunnels handling in FsRtl, Art code for MCBs and CC. Finally, I come with notifications (still) and motivation to make all that stuff working together (which is not, at the moment). This is a very, very interesting experiment since it kinda stresses ReactOS and forces me to work on ReactOS part I promised I would never work on (I am speaking of CC!). On another side, I will also keep on working on other parts of the kernel as I did previously, trying to improve it and match Windows 2003. I will also switch a bit on FreeLDR, some bugs are calling me there!

About personal projects, I have been quite active during 2010, even if I did not publish about them. One of the project I wanted to publish about before I forgot is a C++ garbage collector. I designed it for several uses, and finally it is more a memory manager than a garbage collector. Its purpose is simple: giving you memory whenever you need it and keeping track about it. It can also performs some operations on it to make your program debug easier such as: memory marking, memory zone tagging. It can also allocate non-paged memory, check against corruption, and so on. It has been designed to work in multi-threaded environment and provides functions for that. For example, when you share memory zones between threads, sometimes you even do not recall who is using what, how long. Here garbage collector becomes useful. Each threads when it uses a zone just needs to reference the memory zone. And once it is done, it dereferences it. Simple mechanism, but that ensure the memory zone will be released once every thread is done with it.
I am not totally done with that project (that is perhaps why I did not publish about it yet) and I plan to finish it and make it a bit closer to a garbage collector. And giving it the ability to allocate and release objects.

Other project I have been working on (and I am still actively working on) is an IRCd “new generation” written in C++. Its purpose is quite simple, implementing the five RFC concerning IRC, optionally adding extra often used/needed features. But, the new thing is that it comes with services implemented in (if built with, of course!). This is quite new, and interesting in my opinion. When you need to rapidly deploy an IRCd, configuring both IRCd, services (when you found the good ones!) can be a pain. With that IRCd, everything comes in. Thus it makes services really efficient as they directly communicate with the server (in a proper way, nothing messy!). And there is no need for SVSMODE, SVSJOIN, etc, commands or equivalents, here you just use services. At the moment, the core IRCd is almost complete and works really well. Services are mostly non existant (excepted OpServ, obviously).
For 2011, I plan to finish that IRCd, and perhaps to use it on heisspiter.net. Time will tell.

Finally, this is the shortened version, but there would be so much to say… Best thing is to keep reading ReactOS’ mailing-lists and this blog to keep informed!

Happy new year ;).

Recently, for one of the projets I’m working on, I’ve been asked a really naive question: “How can I be sure a function pointer is valid?”. If the question is naive, the answer isn’t that easy to find. In most programs, when pointers are checked, we just check whether the pointer is null. If not, we assume the pointer is valid. If that test is sufficient for most cases, it happens sometimes it’s not enough.

So my goal here was to find a way to catch wrong non null pointers. I immediately thought about huge and crappy solutions where pointer checks would have been slower than crashing and restarting.
Then, close to the end, you do stupid stuff, such as typing: man end. Here was the solution. 3 external variables are provided by ld when linking a program, and defined by loader when a program is started: etext, edata, end.
Let’s switch back to the structure of a binary. When you build a program, using GCC and without playing with sections, your program is cut into 3 parts: .text, .data, .bss. Interesting part for us is .text. This is were program code is stored. So, when you’re using a function pointer, its address will point into .text section, or it’s not valid. etext meaning end of text (section) is the address of the first instruction after the text section, so every pointer address has to be lower than etext. This gives the first way to check a function pointer. Then, I wondered: pointer has to be higher than something. What? And how to know. What was easy to find: base address of the binary in memory. Indeed, when you start a program, its code is stored in memory. So, I had to find the address of the first instruction. How? While browsing the web, I found that another symbol was also provided by ld: start. This is the address of the entrypoint of the program in memory (most of the time, the main() function of a program is the entrypoint). And most of the time, OS when loading a program puts entrypoint at the begin of the text section in memory.
So, I wrote the following function:
int is_fct_ptr_valid(void *p)
{
  extern char _etext, _start;
  return (((char*) p < &_etext) && ((char*) p > &_start));
}
This way, you can check in a more accurate way if a pointer function is valid.

Then, another question raised in my brain: “OK, you can check functions pointers in a nice way, what about memory now?”. Memory is something harder to check, and I was again a bit lost about how to proceed. I found a first way: most of the time, memory of a program is stored at the end of the program representation in memory. So, pointer address has be higher than end (cf: previous paragraph). And, in fact, having higher address is easy. You just have to use sbrk(0). sbrk is the function you can use to increment heap size of your program, it takes the size of the increment in parameter. 0 means no increment, so it just returns the current higher address.
So, I implemented that and tested. But it failed. I was really stupid thinking that would always work. In fact, in a program, you’ve got two kinds of memory: heap and stack. The method described above is only good at checking heap. Now, the question was: how to check stack then? There was no direct method way to check it, as it was possible for all the rest. Then, I thought about something a bit tricking. When you call a function, memory for local variables is allocated from stack. In fact, you just substract size you need from SP (Stack Pointer) and then, use stack past that given SP. And you do it each time you call a function, even inside another function. And main() is the main function. Then, if you know the address of the stack in main, you know that every other pointer has to be lower than it. And when you call the function to check memory, you know that’s the last called function, so that the pointer to check has to be higher than a pointer you would have in the function. The tricky method was born.
char * sstack;
int is_mem_ptr_valid(void *p)
{
  char estack = 0;
  extern char _end;
  return (((((char*) p > &_end) && (p < sbrk(0))) || (((char*) p < sstack) && ((char*) p > &estack))));
}
int main()
{
  char start_stack;
  sstack = &start_stack;
  /* … */
}
Here, you have the whole process to check memory.

Now, the test program, to show you the whole process:

/* Pointers checkings example */
/* Author: Pierre Schweitzer */

  return 0;
}

The functions given above, even if they are more accurate, are not fail-proof. Several assertions have been made because they are true in most cases. But, in case you don’t have contiguous memory, in case entrypoint isn’t at the begin of memory, those functions would be senseless. Furthermore, those functions only check if pointer points to a valid memory zone, not if the content are valid. Your program can still have issue due to of-by-one mistakes or such.
But, that’s a nice way to begin!