Imagine you have a Linux kernel image for an Android phone, but you don t have the corresponding source, nor do you have the corresponding kernel headers. Imagine that kernel has module support (fortunately), and that you d like to build a module for it to load. There are several good reasons why you can t just build a new kernel from source and be done with it (e.g. the resulting kernel lacks support for important hardware, like the LCD or touchscreen). With the ever-changing Linux kernel ABI, and the lack of source and headers, you d think you re pretty much in a dead-end.
As a matter of fact, if you build a kernel module against different kernel headers, the module will fail to load with errors depending on how different they are. It can complain about bad signatures, bad version or other different things.
But more on that later.
Configuring a kernel
The first thing is to find a kernel source for something close enough to the kernel image you have. That s probably the trickiest part with getting a proper configuration. Start from the version number you can read from
/proc/version. If, like me, you re targeting an Android device, try Android kernels from Code Aurora, Linaro, Cyanogen or Android, whichever is closest to what is in your phone. In my case, it was msm-3.0 kernel. Note you don t necessarily need the exact same version. A minor version difference is still likely to work. I ve been using a 3.0.21 source, which the kernel image was 3.0.8. Don t however try e.g. using a 3.1 kernel source when the kernel you have is 3.0.x.
If the kernel image you have is kind enough to provide a
/proc/config.gz file, you can start from there, otherwise, you can try starting from the default configuration, but you need to be extra careful, then (although I won t detail using the default configuration because I was fortunate enough that I didn t have to, there will be some details further below as to why a proper configuration is important).
Assuming
arm-eabi-gcc is in your
PATH, and that you have a shell opened in the kernel source directory, you need to start by configuring the kernel and install headers and scripts:
$ mkdir build
$ gunzip -c config.gz > build/.config # Or whatever you need to prepare a .config
$ make silentoldconfig prepare headers_install scripts ARCH=arm CROSS_COMPILE=arm-eabi- O=build KERNELRELEASE= adb shell uname -r
The
silentoldconfig target is likely to ask you some questions about whether you want to enable some things. You may want to opt for the default, but that may also not work properly.
You may use something different for
KERNELRELEASE, but it needs to match the exact kernel version you ll be loading the module from.
A simple module
To create a dummy module, you need to create two files: a source file, and a
Makefile.
Place the following content in a
hello.c file, in some dedicated directory:
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
#include <linux/init.h> /* Needed for the macros */
static int __init hello_start(void)
printk(KERN_INFO "Hello world\n");
return 0;
static void __exit hello_end(void)
printk(KERN_INFO "Goodbye world\n");
module_init(hello_start);
module_exit(hello_end);
Place the following content in a
Makefile under the same directory:
obj-m = hello.o
Building such a module is pretty straightforward, but at this point, it won t work yet. Let me enter some details first.
The building of a module
When you normally build the above module, the kernel build system creates a
hello.mod.c file, which content can create several kind of problems:
MODULE_INFO(vermagic, VERMAGIC_STRING);
VERMAGIC_STRING is derived from the
UTS_RELEASE macro defined in
include/generated/utsrelease.h, generated by the kernel build system. By default, its value is derived from the actual kernel version, and git repository status. This is what setting
KERNELRELEASE when configuring the kernel above modified. If
VERMAGIC_STRING doesn t match the kernel version, loading the module will lead to the following kind of message in
dmesg:
hello: version magic '3.0.21-perf-ge728813-00399-gd5fa0c9' should be '3.0.8-perf'
Then, there s the module definition.
struct module __this_module
__attribute__((section(".gnu.linkonce.this_module"))) =
.name = KBUILD_MODNAME,
.init = init_module,
#ifdef CONFIG_MODULE_UNLOAD
.exit = cleanup_module,
#endif
.arch = MODULE_ARCH_INIT,
;
In itself, this looks benign, but the
struct module, defined in
include/linux/module.h comes with an unpleasant surprise:
struct module
(...)
#ifdef CONFIG_UNUSED_SYMBOLS
(...)
#endif
(...)
/* Startup function. */
int (*init)(void);
(...)
#ifdef CONFIG_GENERIC_BUG
(...)
#endif
#ifdef CONFIG_KALLSYMS
(...)
#endif
(...)
(... plenty more ifdefs ...)
#ifdef CONFIG_MODULE_UNLOAD
(...)
/* Destruction function. */
void (*exit)(void);
(...)
#endif
(...)
This means for the
init pointer to be at the right place,
CONFIG_UNUSED_SYMBOLS needs to be defined according to what the kernel image uses. And for the
exit pointer, it s
CONFIG_GENERIC_BUG,
CONFIG_KALLSYMS,
CONFIG_SMP,
CONFIG_TRACEPOINTS,
CONFIG_JUMP_LABEL,
CONFIG_TRACING,
CONFIG_EVENT_TRACING,
CONFIG_FTRACE_MCOUNT_RECORD and
CONFIG_MODULE_UNLOAD.
Start to understand why you re supposed to use the exact kernel headers matching your kernel?
Then, the symbol version definitions:
static const struct modversion_info ____versions[]
__used
__attribute__((section("__versions"))) =
0xsomehex, "module_layout" ,
0xsomehex, "__aeabi_unwind_cpp_pr0" ,
0xsomehex, "printk" ,
;
These come from the
Module.symvers file you get with your kernel headers. Each entry represents a symbol the module requires, and what signature it is expected to have. The first symbol,
module_layout, varies depending on what
struct module looks like, i.e. depending on which of the config options mentioned above are enabled. The second,
__aeabi_unwind_cpp_pr0, is an ARM ABI specific function, and the last, is for our
printk function calls.
The signature for each function symbol may vary depending on the kernel code for that function, and the compiler used to compile the kernel. This means that if you have a kernel you built from source, modules built for that kernel, and rebuild the kernel after modifying e.g. the
printk function, even in a compatible way, the modules you built initially won t load with the new kernel.
So, if we were to build a kernel from the hopefully close enough source code, with the hopefully close enough configuration, chances are we wouldn t get the same signatures as the binary kernel we have, and it would complain as follows, when loading our module:
hello: disagrees about version of symbol symbol_name
Which means we need a proper
Module.symvers corresponding to the binary kernel, which, at the moment, we don t have.
Inspecting the kernel
Conveniently, since the kernel has to do these verifications when loading modules, it actually contains a list of the symbols it exports, and the corresponding signatures. When the kernel loads a module, it goes through all the symbols the module requires, in order to find them in its own symbol table (or other modules symbol table when the module uses symbols from other modules), and check the corresponding signature.
The kernel uses the following function to search in its symbol table (in
kernel/module.c):
bool each_symbol_section(bool (*fn)(const struct symsearch *arr,
struct module *owner,
void *data),
void *data)
struct module *mod;
static const struct symsearch arr[] =
__start___ksymtab, __stop___ksymtab, __start___kcrctab,
NOT_GPL_ONLY, false ,
__start___ksymtab_gpl, __stop___ksymtab_gpl,
__start___kcrctab_gpl,
GPL_ONLY, false ,
__start___ksymtab_gpl_future, __stop___ksymtab_gpl_future,
__start___kcrctab_gpl_future,
WILL_BE_GPL_ONLY, false ,
#ifdef CONFIG_UNUSED_SYMBOLS
__start___ksymtab_unused, __stop___ksymtab_unused,
__start___kcrctab_unused,
NOT_GPL_ONLY, true ,
__start___ksymtab_unused_gpl, __stop___ksymtab_unused_gpl,
__start___kcrctab_unused_gpl,
GPL_ONLY, true ,
#endif
;
if (each_symbol_in_section(arr, ARRAY_SIZE(arr), NULL, fn, data))
return true;
(...)
The
struct used in this function is defined in
include/linux/module.h as follows:
struct symsearch
const struct kernel_symbol *start, *stop;
const unsigned long *crcs;
enum
NOT_GPL_ONLY,
GPL_ONLY,
WILL_BE_GPL_ONLY,
licence;
bool unused;
;
Note: this kernel code hasn t changed significantly in the past four years.
What we have above is three (or five, when
CONFIG_UNUSED_SYMBOLS is defined) entries, each of which contains the start of a symbol table, the end of that symbol table, the start of the corresponding signature table, and two flags.
The data is static and constant, which means it will appear as is in the kernel binary. By scanning the kernel for three consecutive sequences of three pointers within the kernel address space followed by two integers with the values from the definitions in
each_symbol_section, we can deduce the location of the symbol and signature tables, and regenerate a
Module.symvers from the kernel binary.
Unfortunately, most kernels these days are compressed (zImage), so a simple search is not possible. A compressed kernel is actually a small bootstrap binary followed by a compressed stream. It is possible to scan the kernel zImage to look for the compressed stream, and decompress it from there.
I wrote a script to do
decompression and extraction of the symbols info automatically. It should work on any recent kernel, provided it is not relocatable and you know the base address where it is loaded. It takes options for the number of bits and endianness of the architecture, but defaults to values suitable for ARM. The base address, however, always needs to be provided. It can be found, on ARM kernels, in
dmesg:
$ adb shell dmesg grep "\.init"
<5>[01-01 00:00:00.000] [0: swapper] .init : 0xc0008000 - 0xc0037000 ( 188 kB)
The base address in the example above is
0xc0008000.
If like me you re interested in loading the module on an Android device, then what you have as a binary kernel is probably a complete boot image. A boot image contains other things besides the kernel, so you can t use it directly with the script. Except if the kernel in that boot image is compressed, in which case the part of the script that looks for the compressed image will find it anyways.
If the kernel is not compressed, you can use the
unbootimg program as outlined in this
old post of mine to get the kernel image out of your boot image. Once you have the kernel image, the script can be invoked as follows:
$ python extract-symvers.py -B 0xc0008000 kernel-filename > Module.symvers
Symbols and signature info could also be extracted from binary modules, but I was not interested in that information so the script doesn t handle that.
Building our module
Now that we have a proper
Module.symvers for the kernel we want to load our module in, we can finally build the module:
(again, assuming
arm-eabi-gcc is in your
PATH, and that you have a shell opened in the kernel source directory)
$ cp /path/to/Module.symvers build/
$ make M=/path/to/module/source ARCH=arm CROSS_COMPILE=arm-eabi- O=build modules
And that s it. You can now copy the resulting
hello.ko onto the device and load it.
and enjoy
$ adb shell
# insmod hello.ko
# dmesg grep insmod
<6>[mm-dd hh:mm:ss.xxx] [id: insmod]Hello world
# lsmod
hello 586 0 - Live 0xbf008000 (P)
# rmmod hello
# dmesg grep rmmod
<6>[mm-dd hh:mm:ss.xxx] [id: rmmod]Goodbye world
FreedomBox 0.1
Ian Sullivan posted a release announcement today regarding the first
FreedomBox public release, which we're
calling 0.1.
This release is, frankly, long overdue. Getting here has been harder and taken
much longer than any of us intended. Fortunately, now that we've reached this
milestone, I believe that making regular progress towards the vision we have
for a "1.0" release will get easier.
FreedomBox is far from the only thing that I'll be working on after my upcoming
early retirement
from HP, but hopefully I will succeed in putting far more
time towards the project soon than I have been able to in the past.
Almost a year has passed since my talk at pgconf.eu 2011 in Amsterdam on
IT S FINALLY IN!
With this last upload of the MiniUPnP daemon 1.7-3, I ve reached a first milestone: all of the MiniUPnP libraries, daemons and clients are finally in Debian, in a shape which I am not ashamed anymore.
What is UPnP for?
Back in the days (around Linux 2.0.3x), the only way to share a single Internet connection was to run a Linux box as your gateway. These days are far gone, and nearly every home connection is done through a mini home router, which also often provides a small switch and a WiFi access point. Every computer on the LAN gets its connectivity through the router thanks to NAT, and to be more accurate, masquerading. That works very well for outbound connections (browse the web, send a mail, etc.), but it is then a lot harder that something connects to a server located in the LAN. If you run a permanent server with a fixed LAN IP address, that s fine, you just configure your router to do some port forwarding, so that any inbound connection will be forwarded to the computer of your choice in the LAN. But if one application needs to listen on the public IP address just for a while (for example, IRC using DCC connection), so that something can connect to it, it becomes a way more tricky. That s when UPnP comes into play. UPnP stands for Universal Plug and Play. It s a protocol so that any application on the LAN can open ports on the public IP address of the gateway. Note that an UPnP router is also often referenced as UPnP IGD (Internet Gateway Device).
Why using MiniUPnP, don t we have already linux-igd?
Before my packaging work, the only UPnP server that was available in Debian was linux-igd, which has a dependency on libupnpX. That library is quite big for what it does (about 500KiB, on top of which you have to install the 200KiB daemon itself), while MiniUPnP is designed to be lightweight (only 158K, with dependencies on iptables, iproute, uuid-runtime and libc6 only). That seems ridiculous, but when you have only 8MiB of flash in your old router, saving few hundreds KiB is really important, and here, we re saving more than 500 KiB, with a full implementation of the UPnP protocol, and the Microsoft NATPmP implemented as well (yes, Microsoft decided that one protocol wasn t enough, and that they should implement their own (sic!)).
Who is using MiniUPNP?
Probably, you already have the libminiupnpc installed in your SID/wheezy desktop, because the transmission bittorent client which is installed with Gnome by default, depends on it, and minissdpd might be in your desktop too, if you installed the Recommends: packages as well. Which is why these are scoring quite high already in popcon. Previously, transmission was embedding its own version of the MiniUPnP client library, so it s nice to have it as a standalone shared library now.
Also, because of its very light weight, and the fact that UPnP is often needed for gaming (both XBOX 360 and PSP need, and can use, the MiniUPnP daemon that runs on your IGD), many ISP who ship a router to their customer, install MiniUPnP in it. For example, at least, the 2nd and 3rd largest Internet access provider in France (Free Telecom and SFR) are shipping MiniUPnPd in their box (one of them using OpenWRT on their router). So probably as well, you are also using MiniUPnP daemon without knowing it.
But isn t UPnP unsafe?
To this question, I d answer that connecting to Internet is unsafe. It isn t less safe than connecting to Internet on a WiFi hotspot for example. So adding UPnP support on your gateway doesn t make it less safe, especially since MiniUPnP has some features to help with security (like an ACL with IP and port lists, or a secure mode were the router will only open ports to the client requesting it). Also, we are running a distribution where dependencies are easy to check, so it s easy for you to check if a client uses UPnP or not, and decide to trust it (or not). I personally have no issue trusting transmission, x-chat or warzone2010 (more exactly: I don t trust that incoming connectivity will make it less safe for these applications, there are so many other things that could go wrong).
MiniUPnP consists of what?
MiniUPnP is a set of 4 source packages to handle all of your UPnP needs:
- The client library, libminiupnpc (and the corresponding -dev package), with its sidekick miniupnpc client program (you can use it to check the public IP of your gateway, or manually open ports).
- The UPnP IGD daemon, miniupnpd, which just reached Debian Experimental. The latest version, 1.7-3, also includes debconf configuration so that you can choose the NIC and IP address to bind on. If you installed previous version, I strongly recommend upgrading to fix previous problems.
- The libnatpmp client library (and the -dev package) for implementing the Microsoft protocol as a client (it also has a client package binary for your tests).
- The minissdpd daemon to keep memory of all UPnP devices that announced themselves, and speed-up using the UPnP protocol (used by the MiniUPnP client library).
A long process to have MiniUPnP in Debian
All these 4 pieces of the puzzle were not as easy as it seems to be packaged in Debian. Especially, the IGD daemon, MiniUPnPd, used to depend on some header files that were not packaged in Debian. This was a decision of the iptables maintainers, which even after a long discussion, refused to add the necessary headers because it wasn t supposed to be a kernel API. While this might really be truth, the issue was that there was no public API available in the Linux kernel at all, and other distributions (Fedora, Gentoo, etc.) really did supply these needed files. As a consequence, during a very long time (years literally), shamefully, it was impossible to build the MiniUPnP daemon in Debian, while it was no problem on other distributions. Note that I do not want to start a troll discussion here, I m just stating facts, both parties have very strong and respectable arguments. Anyway, this needed API was finally embedded in MiniUPnPd itself thanks to a contributor to the project, and now it builds on both the Squeeze and the Wheezy (that is Linux 3.2) kernel without any issue.
Call for testing
Unfortunately, I don t have a Linux box as my Internet gateway. So I did the tests that I could: I installed MiniUPnPd on one computer on my LAN, and checked that I could open ports from another computer. So it seems to work, but I had no way to really test it live , with some real clients. So if you have an Debian SID box as your Internet gateway, feedback would be highly appreciated.
What is remaining to do?
A transition from libminiupnpc5 to libminiupnpc8 has to happen. Of course, this is too late for Wheezy, so this will happen right after the release. There s not so many reverse dependencies, so it should be ok, but I (yet) have zero experience with transitions. BTW, I had hard time to find out what this transition process was, and maybe some more effort for documenting it would help others (I m thinking about adding some text in the Debian wiki for that). Also, I have called for help on debian-devel, because I m currently the only one maintaining all these 4 source packages, and I m trying to have all my packages checked by others, and team maintained. So if you want to give a hand, or just declare yourself as a backup if I m busy, please raise your hand! Upstream is a friend of mine, and is very reactive to any requests (it very rarely took more than 48 hours to get a reply).
Enjoy MiniUPnP and report bugs!
Again, feedback would be appreciated. :)
It is rare that I use social networks, but usually I do not decline
invitations to connect when they come from people I know. This said, I had
doubts when accepting invitations from other Debian Developers, most of whom
I never met in person: how can I be sure that the account really belongs to
the person ? Luckily, we have a tool to solve that problem, our 
I've temporarily got hold of a Retina Macbook Pro. Fedora 17 boots fine on it with the following kernel arguments: nointremap drm_kms_helper.poll=0 video=eDP-1:2880x1800@45e, although you'll want an 
The result was wonderful we immediately were able to deploy schema changes with <= 90 seconds of downtime, which was significantly less than the 5 minutes our stakeholders had agreed to as a benchmark if we were under 5 minutes, we could schedule downtime once a day rather than once a month. We had to fix some API client code to retry more reliably, and likewise fix a few minor bugs in the database connection handling logic in the appservers, but all in all it was a pretty smooth project. Along the way we spun off a small python helper to 
I had to install Debian Wheezy on a brand new Sony Vaio Z laptop with the
new Ivy Bridge architecture (SVZ1311C5E). I'll talk about this here, because
it's always nice to know that new hardware works quite fine (or not) under
Debian.
The laptop is delivered with Window 7, which I decided to remove entirely
anyway, and replace with Debian. I've installed it with Linux 3.2 and then
ran Linux 3.4, 3.5 and 3.6-rc1.
USB booting
Don't ask me why, nor an Ubuntu or Debian USB installation booted, blocked
at SYSLINUX at best, or at a black screen. This does not work. I had to use
PXE to install Debian.
Storage
The only thing that can be surprising, is that the 128 GB SSD storage is
actually made of 2 64 GB Samsung SSD aggregated in a RAID 0 using 
Last week I helped organize the 
Recently, I've started converting many of my subversion repositories
to git, some of which contain fairly large files (2-3G). However, git
can be slow to deal with repositories with large files, and it also
isn't able to selectively discard unneeded files when disk space is
pressing. Thankfully,
TLDR: multiarch, multiarch, multiarch, cross buildability, staged build
dependencies, 
If you're a
DebConf12 speaker and produced slides, please upload them to penta,
so that they could be used as future reference.
So this week I bought a cheap Android tablet, specifically to allow me to read books upon the move and listen to music at home.
Currently my desktop PC has a bunch of music on it, and I listen to it locally only. In my living room I have an iPOD in a dock which has identical contents.
In my bedroom? No music. This was something I wished to change.
The music on my desktop is played via