Changes to the binfmt_elf.c routine in the Linux 2.6.11 kernal now cause a segment fault if the ELF header has a pointer to a read-only .bss section. This causes (e.g.) the "hello" program in ../examples/elfexe to fail. One can argue if the new kernel code is a bug or a feature, but it would be a good idea for the flat assembler developers to fix the problem, since a .bss section which is not writeable isn't of any use, in any case.

-- Chuck

But the fasm's examples don't contain any BSS section at all. As you can see in the source, there is one "section readable writeable" for data and one "section readable executable" for code - these are in fact only segments in the program header, since fasm follows strictly the ELF specification, which states that section headers are optional (thus not needed) for the executables and program headers are optional for the objects.

Nevertheless, when I force a writeable BSS section, by adding the following lines to the example, the problem goes away:

section readable writeable
dummy dd ?

-- Chuck

Maybe the problem is not having BSS section at all? Does the kernel (over)interprete that the last section of program is always the BSS?

You are correct, as I have just verified by digging deeper into the kernel code [binfmt_elf.c], and by running a few tests. The kernel wants to clear the uninitialized part of the last page, and calculates the address to start zeroing by finding the section with the highest physical address pointer, and adding the memory size value for that section.

In the case of the elfexe example program, the last section is the code section, and is not writeable, so the attempt to zero the rest of the page fails. In earlier releases, the return code from the padzero call was not checked, but starting with the 2.6.11 kernel, a non-zero return code causes a segment fault.

Although it seems to me that this new behavior is a kernel bug, I still think that it is in your best interest to change to code to ensure that the last section is something writeable, even if it is only a zero length section.

-- Chuck

This is only the matter of changing the example source - fasm itself just creates the sections in the order and type exactly as it told to do by the source.

Yay for excellent linux kernel programmers - *grin*

Further testing shows that the the "dummy dd ?" in my previous post is not required. Adding "section writable" is sufficient, by itself.

-


Yay for open source kernel development

I 2nd that, wonder how long time would a such design choice would have been an "unknown why" in *cough* *cough* ...
btw, does this behaviour still exist in 2.6.12? (haven't dug the sources at time of writing, I wonder is it documented or possibly a thing that should be patched asap?)

Yes, I am now running 2.6.12-1.1387_FC4, and the behaviour is unchanged. As far as I know, elfexe is the only publicly distributed code which shows this problem , so I fear that it will go down in history as a flat assembler bug.

-- Chuck

...even though, considering the nature of things, it's a linux bug.

Yes, even though . . .

-- Chuck

Thanks for the info. I was wandering why my code was no longer working!

Anyone knows if the newer versions of the linux kernel has this problem too? Someone had reported this to the Linux developers?

i has to travel to past of slashdot and fetch some information why there are change to elf in 2.6.11 heh...

here two links:

http://it.slashdot.org/article.pl?sid=05/05/30/1111206
http://lwn.net/Articles/136516/

cheer.

A fix for this problem was included in 2.6.14. I have tested it with 2.6.15 and 2.6.16, and agree that the problem is now fixed.

-- Chuck

Thanks chuck!!

OK, i am going to un-Sticky this thread