| View previous topic :: View next topic |
| Author |
Message |
Francesco Salvestrini
Guest
|
 Posted: Tue Jul 01, 2008 3:28 am Post subject: ELF image format |
 |
|
Hi all,
I've an old-unresolved issue regarding the elf/multiboot image file format;
I would be glad to know if someone knows a better solution than the hack
I'm currently using.
The problem seems quite simple: in order to have a multiboot compliant
kernel image the multiboot header must be placed in the first 8KB (both for
multiboot-1 and multiboot-2 specifications, as it seems) of the kernel
image file (elf).
In order to satisfy this constraint I'm linking all my objects in a single
shoot, giving them the appropriate order. This means that I have to place
the "multiboot" header object at first in the linking line, in order to
have the header in the first KBs of the resulting output file:
# OK
gcc multiboot.o obj1.o obj2.o etc.o ... -o kernel
# KO
gcc obj1.o obj2.o etc.o ... multiboot.o -o kernel
(NOTE: multiboot.o has the "multiboot" header)
The solution is a bare hack (which works in my environment and in some
other, maybe); I would be glad to solve the problem in a general way.
Does anybody knows how to *really* solve the problem?
Cheers,
Francesco
--
flannister, n.:
The plastic yoke that holds a six-pack of beer together.
-- "Sniglets", Rich Hall & Friends |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Kristof Benes
Guest
|
| Posted: Tue Jul 01, 2008 4:26 am Post subject: Re: ELF image format |
|
|
Francesco Salvestrini wrote:
| Quote: |
Hi all,
I've an old-unresolved issue regarding the elf/multiboot image file format;
I would be glad to know if someone knows a better solution than the hack
I'm currently using.
The problem seems quite simple: in order to have a multiboot compliant
kernel image the multiboot header must be placed in the first 8KB (both for
multiboot-1 and multiboot-2 specifications, as it seems) of the kernel
image file (elf).
In order to satisfy this constraint I'm linking all my objects in a single
shoot, giving them the appropriate order. This means that I have to place
the "multiboot" header object at first in the linking line, in order to
have the header in the first KBs of the resulting output file:
# OK
gcc multiboot.o obj1.o obj2.o etc.o ... -o kernel
# KO
gcc obj1.o obj2.o etc.o ... multiboot.o -o kernel
(NOTE: multiboot.o has the "multiboot" header)
The solution is a bare hack (which works in my environment and in some
other, maybe); I would be glad to solve the problem in a general way.
Does anybody knows how to *really* solve the problem?
Cheers,
Francesco
Hi Francesco, |
If just putting the one object first in your list works, that sounds
like an easy way to handle it. I assume you have a makefile for your OS
project, you can handle it in there in one of two ways:
....
OBJS = multiboot.o \
keyboard.o \
...
last_file.o
and when you add new files, just place them towards the end, but not the
last one that way in vi you can just yyp^cw filename. Or if you wanted
to get fancier...
....
MULTIBOOT = multiboot.o
KRNL_OBJS = obj1.o \
obj2.o
$(KERNEL_ELF): $(MULTIBOOT) $(KRNL_OBJS)
$(LD) $(MULTIBOOT) $(KRNL_OBJS) -o $(KERNEL_ELF) $(LDFLAGS)
Then you could change the order of KRNL_OBJS all you want. Although in
my experience adding files using a copy of the line above seems to work
pretty well, and leaves you with the same initial and ending file. In
mine for example, the entry object is always the first one, and the 8259
code is always the last, the others get added somewhere in the middle.
I guess it depends on your development model. You sound quite a bit
further along than I am, so maybe youve got libraries and/or reusable
object files and other such things or a complicated link process. In
that case maybe treat multiboot.o as a stand alone library that always
needs to be linked first.
I guess I'm not sure what you mean by a "general" way?
Every OS is different. Compiling a kernel is an exception rather than
the rule, so having a few odd build steps makes perfect sense, in fact
its sort of a given. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Maxim S. Shatskih
Guest
|
| Posted: Tue Jul 01, 2008 9:19 pm Post subject: Re: ELF image format |
|
|
Named sections with alphabetic order?
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
"Francesco Salvestrini" <salvestrini@gmail.com> wrote in message
news:g4bmrd$ie3$1@aioe.org...
| Quote: |
Hi all,
I've an old-unresolved issue regarding the elf/multiboot image file format;
I would be glad to know if someone knows a better solution than the hack
I'm currently using.
The problem seems quite simple: in order to have a multiboot compliant
kernel image the multiboot header must be placed in the first 8KB (both for
multiboot-1 and multiboot-2 specifications, as it seems) of the kernel
image file (elf).
In order to satisfy this constraint I'm linking all my objects in a single
shoot, giving them the appropriate order. This means that I have to place
the "multiboot" header object at first in the linking line, in order to
have the header in the first KBs of the resulting output file:
# OK
gcc multiboot.o obj1.o obj2.o etc.o ... -o kernel
# KO
gcc obj1.o obj2.o etc.o ... multiboot.o -o kernel
(NOTE: multiboot.o has the "multiboot" header)
The solution is a bare hack (which works in my environment and in some
other, maybe); I would be glad to solve the problem in a general way.
Does anybody knows how to *really* solve the problem?
Cheers,
Francesco
--
flannister, n.:
The plastic yoke that holds a six-pack of beer together.
-- "Sniglets", Rich Hall & Friends
|
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Francesco Salvestrini
Guest
|
| Posted: Wed Jul 02, 2008 2:17 am Post subject: Re: ELF image format |
|
|
Maxim S. Shatskih wrote:
| Quote: |
Named sections with alphabetic order?
|
It does not constraint the linker to place sections in alphabetical order,
look at section-names/file-offsets:
$ objdump -h src/kernel
src/kernel: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0001725c 00100000 00100000 00001000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .syscall 0000005c 00117260 00117260 00018260 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .rodata 00006b69 001172c0 001172c0 000182c0 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .gcc_except_table 0000002e 0011de2c 0011de2c 0001ee2c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .data 00000c60 0011de60 0011de60 0001ee60 2**5
CONTENTS, ALLOC, LOAD, DATA
5 .got 00000020 0011eac0 0011eac0 0001fac0 2**2
CONTENTS, ALLOC, LOAD, DATA
6 .got.plt 0000000c 0011eae0 0011eae0 0001fae0 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .bss 00009ed4 0011eb00 0011eb00 0001faec 2**5
ALLOC
8 .debug 0005cf45 001289d8 001289d8 0001faf0 2**3
CONTENTS, READONLY, DEBUGGING
9 ...
...
Cheers,
Francesco
--
Smoking Prohibited. Absolutely no ifs, ands, or butts. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Francesco Salvestrini
Guest
|
| Posted: Wed Jul 02, 2008 3:11 am Post subject: Re: ELF image format |
|
|
Kristof Benes wrote:
| Quote: |
Francesco Salvestrini wrote:
Hi all,
I've an old-unresolved issue regarding the elf/multiboot image file
format; I would be glad to know if someone knows a better solution than
the hack I'm currently using.
The problem seems quite simple: in order to have a multiboot compliant
kernel image the multiboot header must be placed in the first 8KB (both
for multiboot-1 and multiboot-2 specifications, as it seems) of the
kernel image file (elf).
In order to satisfy this constraint I'm linking all my objects in a
single shoot, giving them the appropriate order. This means that I have
to place the "multiboot" header object at first in the linking line, in
order to have the header in the first KBs of the resulting output file:
# OK
gcc multiboot.o obj1.o obj2.o etc.o ... -o kernel
# KO
gcc obj1.o obj2.o etc.o ... multiboot.o -o kernel
(NOTE: multiboot.o has the "multiboot" header)
The solution is a bare hack (which works in my environment and in some
other, maybe); I would be glad to solve the problem in a general way.
Does anybody knows how to *really* solve the problem?
Cheers,
Francesco
Hi Francesco,
If just putting the one object first in your list works, that sounds
like an easy way to handle it. I assume you have a makefile for your OS
project, you can handle it in there in one of two ways:
...
OBJS = multiboot.o \
keyboard.o \
...
last_file.o
and when you add new files, just place them towards the end, but not the
last one that way in vi you can just yyp^cw filename. Or if you wanted
to get fancier...
...
MULTIBOOT = multiboot.o
KRNL_OBJS = obj1.o \
obj2.o
$(KERNEL_ELF): $(MULTIBOOT) $(KRNL_OBJS)
$(LD) $(MULTIBOOT) $(KRNL_OBJS) -o $(KERNEL_ELF) $(LDFLAGS)
Then you could change the order of KRNL_OBJS all you want. Although in
my experience adding files using a copy of the line above seems to work
pretty well, and leaves you with the same initial and ending file. In
mine for example, the entry object is always the first one, and the 8259
code is always the last, the others get added somewhere in the middle.
I guess it depends on your development model. You sound quite a bit
further along than I am, so maybe youve got libraries and/or reusable
object files and other such things or a complicated link process. In
that case maybe treat multiboot.o as a stand alone library that always
needs to be linked first.
I guess I'm not sure what you mean by a "general" way?
Every OS is different. Compiling a kernel is an exception rather than
the rule, so having a few odd build steps makes perfect sense, in fact
its sort of a given.
|
I'm looking for a solution with the less number of constraints as possible.
There are three possible solutions IMHO:
1) Place the multiboot header object first in the link line
PRO: Easy
CON1: The command line could get too long if you have too many objects to
link (use libraries/archives to solve the problem)
CON2: The solution relies on the linker behaviour and depends directly on
the linker implementation
2) Have a short (size < 8KB) multiboot compliant elf image which get loaded
by a multiboot compliant loader, the image "loads" all your modules (the
kernel is a "module" itself) afterward.
PRO: No link order necessary
CON: Needs code to dynamically load the elf "modules". If you have dynamic
loading related code already ... there should be no problems.
3) Rearrange the kernel elf structure using libbfd: scan the input kernel
elf image rearranging the sections on-the-fly, in order to have the section
containing the multiboot header at first in the output file.
PROS: No link order necessary
CONS1: The multiboot header must be placed at offset < 8KB from the
beginning of the section that must be moved on top of the elf image (a
single section containing only the multiboot header solve the problem).
CONS2: Not so easy, needs a bit-of-elf-image-format-knowledge
The last solution is the one I'm concentrating on, at the moment. Have you a
better idea ?
Thanks
Francesco
--
There will always be beer cans rolling on the floor of your car when
the boss asks for a lift home from the office. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Kristof Benes
Guest
|
| Posted: Thu Jul 03, 2008 2:30 am Post subject: Re: ELF image format |
|
|
Francesco Salvestrini wrote:
| Quote: |
Kristof Benes wrote:
Francesco Salvestrini wrote:
Hi all,
I've an old-unresolved issue regarding the elf/multiboot image file
format; I would be glad to know if someone knows a better solution than
the hack I'm currently using.
The problem seems quite simple: in order to have a multiboot compliant
kernel image the multiboot header must be placed in the first 8KB (both
for multiboot-1 and multiboot-2 specifications, as it seems) of the
kernel image file (elf).
In order to satisfy this constraint I'm linking all my objects in a
single shoot, giving them the appropriate order. This means that I have
to place the "multiboot" header object at first in the linking line, in
order to have the header in the first KBs of the resulting output file:
# OK
gcc multiboot.o obj1.o obj2.o etc.o ... -o kernel
# KO
gcc obj1.o obj2.o etc.o ... multiboot.o -o kernel
(NOTE: multiboot.o has the "multiboot" header)
The solution is a bare hack (which works in my environment and in some
other, maybe); I would be glad to solve the problem in a general way.
Does anybody knows how to *really* solve the problem?
Cheers,
Francesco
Hi Francesco,
If just putting the one object first in your list works, that sounds
like an easy way to handle it. I assume you have a makefile for your OS
project, you can handle it in there in one of two ways:
...
OBJS = multiboot.o \
keyboard.o \
...
last_file.o
and when you add new files, just place them towards the end, but not the
last one that way in vi you can just yyp^cw filename. Or if you wanted
to get fancier...
...
MULTIBOOT = multiboot.o
KRNL_OBJS = obj1.o \
obj2.o
$(KERNEL_ELF): $(MULTIBOOT) $(KRNL_OBJS)
$(LD) $(MULTIBOOT) $(KRNL_OBJS) -o $(KERNEL_ELF) $(LDFLAGS)
Then you could change the order of KRNL_OBJS all you want. Although in
my experience adding files using a copy of the line above seems to work
pretty well, and leaves you with the same initial and ending file. In
mine for example, the entry object is always the first one, and the 8259
code is always the last, the others get added somewhere in the middle.
I guess it depends on your development model. You sound quite a bit
further along than I am, so maybe youve got libraries and/or reusable
object files and other such things or a complicated link process. In
that case maybe treat multiboot.o as a stand alone library that always
needs to be linked first.
I guess I'm not sure what you mean by a "general" way?
Every OS is different. Compiling a kernel is an exception rather than
the rule, so having a few odd build steps makes perfect sense, in fact
its sort of a given.
I'm looking for a solution with the less number of constraints as possible.
There are three possible solutions IMHO:
1) Place the multiboot header object first in the link line
PRO: Easy
CON1: The command line could get too long if you have too many objects to
link (use libraries/archives to solve the problem)
CON2: The solution relies on the linker behaviour and depends directly on
the linker implementation
2) Have a short (size < 8KB) multiboot compliant elf image which get loaded
by a multiboot compliant loader, the image "loads" all your modules (the
kernel is a "module" itself) afterward.
PRO: No link order necessary
CON: Needs code to dynamically load the elf "modules". If you have dynamic
loading related code already ... there should be no problems.
3) Rearrange the kernel elf structure using libbfd: scan the input kernel
elf image rearranging the sections on-the-fly, in order to have the section
containing the multiboot header at first in the output file.
PROS: No link order necessary
CONS1: The multiboot header must be placed at offset < 8KB from the
beginning of the section that must be moved on top of the elf image (a
single section containing only the multiboot header solve the problem).
CONS2: Not so easy, needs a bit-of-elf-image-format-knowledge
The last solution is the one I'm concentrating on, at the moment. Have you a
better idea ?
Thanks
Francesco
I've never delved into the world of multiboot, and the only question I |
have is is the multiboot header in its own section ie not .text or
..data, but something else, like .mboot or something? If so, you could
probably relocate it with link options. For gnu ld its -Ttext=.... and
you can specify additional sections too, so like say its loaded at
0x10000, you could do -Ttext 0x10200 -Tmboot 0x10000 (assuming an 8kb
size). Worst comes to worst you could always do "cat mboot.bin
kernel.elf > kernel.bin" and load kernel.bin . I do something similar
in mine I have 16 bit video switching code that just gets globbed onto
the front of the kernel elf itself.
If you want to get really ninja and modify the elf structure itself,
look at http://www.cs.ucdavis.edu/~haungs/paper/node10.html I used the
info in there to construct my elf unpacker.
Of course all of that assumes that the mboot section is in its own
section. If its in the text or data section youre screwed. Those can
be interspersed anywhere especially with optimized code. And elf
manipulation wont work under all compilers, which it sounds like you are
trying to do. DJGPP for instance uses a.out which is totally different.
Even some older versions of FreeBSD still use a.out.
Most linkers, especially ones that create elf formats generally follow
the order that the object files are passed in. The few a.out linkers
I've seen do the same as well. Even Micro$oft VC++ linker uses the same
idea for its proprietary object format (PE). I'm sure there are some
compilers out there that do relocate stuff wherever it would fit best,
but they probably arent even designed for the x86 platform. So my guess
is your pretty much safe with option 1. Although it is fun to mess with
an executable file and still have it work. :-)
More links to good ELF resources can be found in wikipedia
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Rod Pemberton
Guest
|
| Posted: Thu Jul 03, 2008 5:47 am Post subject: Re: ELF image format |
|
|
"Kristof Benes" <chris@nospammaricopacomputer.com> wrote in message
news:g4gs1t$pf6$1@news2.open-news-network.org...
| Quote: |
I used the
info in there to construct my elf unpacker.
|
Is this available?
| Quote: |
Of course all of that assumes that the mboot section is in its own
section. If its in the text or data section youre screwed. Those can
be interspersed anywhere especially with optimized code. And elf
manipulation wont work under all compilers, which it sounds like you are
trying to do.
DJGPP for instance uses a.out which is totally different.
Even some older versions of FreeBSD still use a.out.
|
DJGPP also has the DPMI startup code at the beginning which takes up more
than 8k. There might be some blank space in there, but that'd probably
require studying DJGPP packers/unpackers and an additional utility to insert
the MB header into the empty space. IIRC, Alexei recommended a linker
script to me a while back to solve the problem of getting the MB header into
the first 8k. Of course, if the MB header is down low (below 8k), then the
..exe won't work in the host OS - which isn't a problem once the OS is
complete.
Rod Pemberton |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Rod Pemberton
Guest
|
| Posted: Thu Jul 03, 2008 5:48 am Post subject: Re: ELF image format |
|
|
"Francesco Salvestrini" <salvestrini@gmail.com> wrote in message
news:g4bmrd$ie3$1@aioe.org...
[MB header into first 8k with C]
| Quote: |
Does anybody knows how to *really* solve the problem?
|
No, but this would likely be my approach:
1) write blank MB header in assembly
2) assemble MB header to raw binary object
3) write util to extract info from OS image and calculate proper MB header
fields
4) concatenate/prepend/copy OS image together with binary MB header placed
at the start
5) write util to update MB header fields with correct values from 3)
Standard OS utils exist for 1, 2, and 4. 5 could be written portably in C
for any OS that supports files. Part of 3 is image type dependent: a.out,
ELF, COFF, etc and may have other complications (i.e., relocation). The
rest could be done in portable C.
(You might want to look at linker scripts...)
Rod Pemberton |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
BG
Guest
|
| Posted: Thu Jul 03, 2008 4:53 pm Post subject: Re: ELF image format |
|
|
"Francesco Salvestrini" <salvestrini@gmail.com> wrote in message
news:g4e72m$9k$1@aioe.org...
| Quote: |
Maxim S. Shatskih wrote:
Named sections with alphabetic order?
It does not constraint the linker to place sections in alphabetical order,
look at section-names/file-offsets:
$ objdump -h src/kernel
src/kernel: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0001725c 00100000 00100000 00001000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .syscall 0000005c 00117260 00117260 00018260 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .rodata 00006b69 001172c0 001172c0 000182c0 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .gcc_except_table 0000002e 0011de2c 0011de2c 0001ee2c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .data 00000c60 0011de60 0011de60 0001ee60 2**5
CONTENTS, ALLOC, LOAD, DATA
5 .got 00000020 0011eac0 0011eac0 0001fac0 2**2
CONTENTS, ALLOC, LOAD, DATA
6 .got.plt 0000000c 0011eae0 0011eae0 0001fae0 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .bss 00009ed4 0011eb00 0011eb00 0001faec 2**5
ALLOC
8 .debug 0005cf45 001289d8 001289d8 0001faf0 2**3
CONTENTS, READONLY, DEBUGGING
9 ...
...
Cheers,
Francesco
--
Smoking Prohibited. Absolutely no ifs, ands, or butts.
|
Write your own link script then use it with ld like so
ld -T location/of/link/script.lds ....
In the following example, place the multiboot stuff in section ".init"
-----------------------------8<-------------------------------------------------------
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(arch_entry_point)
SECTIONS
{
/*
* Set the image base pointer
*/
LINKSCRIPT_IMAGEBASE = 0x00400000;
. = 0x00400000;
/*
* The text and rodata section
*/
.text (LINKSCRIPT_IMAGEBASE) : AT(LINKSCRIPT_IMAGEBASE)
{
*(.init) /* MULTIBOOT SECTION */
*(.text)
. = ALIGN(16);
*(.rodata)
*(.rodata.*)
} = 0x9090
/*
* The data section
*/
. = ALIGN(4096); .data BLOCK(4096)
:
{
*(.data)
}
. = ALIGN(4096);
.rsrc BLOCK(4096) :
{
*(.rsrc)
}
/*
* Now for the BSS section
*/
. = ALIGN(4096);
.bss BLOCK(4096) :
{
*(.bss)
*(COMMON)
}
/*
* Sections to discard
*/
/DISCARD/ :
{
*(.text.exit)
*(.data.exit)
*(.exitcall.exit)
*(.stab)
*(.stabstr)
*(.stab.excl)
*(.stab.exclstr)
*(.stab.index)
*(.stab.indexstr)
*(.comment)
*(.note)
}
/*
* Finally, this points to the end of the image
*/
. = ALIGN(4096);
LINKSCRIPT_IMAGEEND = .;
} |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Kristof Benes
Guest
|
| Posted: Thu Jul 03, 2008 8:43 pm Post subject: Re: ELF image format |
|
|
Rod Pemberton wrote:
| Quote: |
"Kristof Benes" <chris@nospammaricopacomputer.com> wrote in message
news:g4gs1t$pf6$1@news2.open-news-network.org...
I used the
info in there to construct my elf unpacker.
Is this available?
Of course all of that assumes that the mboot section is in its own
section. If its in the text or data section youre screwed. Those can
be interspersed anywhere especially with optimized code. And elf
manipulation wont work under all compilers, which it sounds like you are
trying to do.
DJGPP for instance uses a.out which is totally different.
Even some older versions of FreeBSD still use a.out.
DJGPP also has the DPMI startup code at the beginning which takes up more
than 8k. There might be some blank space in there, but that'd probably
require studying DJGPP packers/unpackers and an additional utility to insert
the MB header into the empty space. IIRC, Alexei recommended a linker
script to me a while back to solve the problem of getting the MB header into
the first 8k. Of course, if the MB header is down low (below 8k), then the
.exe won't work in the host OS - which isn't a problem once the OS is
complete.
Rod Pemberton
Sure, this is all in NASM [BITS 32] section, it assumes the file has |
been loaded at 0x10000 and a20 is already enabled, pmode is on etc...
; Here we unpack the ELF file into where it needs to go
; First validate that it is an ELF file
cmp DWORD [0x10000],0x464c457f ; The ELF signature is \07fELF
jne ldr_ELF_err ; Ugh... not an ELF file !!!
cmp WORD [0x10004],0x101 ; It should be statically linked
etc.
jne ldr_ELF_err
cmp BYTE [0x10006],1
jne ldr_ELF_err
jmp skip_err_handler ; Ok, looks like its an elf file
; Not an elf file, so we write ELF in the top left corner of screen
; Can not use BIOS since we are in Pmode
ldr_ELF_err:
mov WORD [0xb8000],0x0700 + 'E';
mov WORD [0xb8002],0x0700 + 'L';
mov WORD [0xb8004],0x0700 + 'F';
cli
hlt
skip_err_handler:
mov DWORD eax, [0x10018] ; Store entry point address for
later use
mov [krnl_entry], eax
xor ecx,ecx ; Get the number of sections in cx
mov cx,[0x1002c]
sectionloop:
dec cx ; Next section
push cx ; Save cx on the stack while we
load the section into memory
xor eax,eax
mov WORD ax,[0x1002a] ; Get the program header entry size
mul cx ; Calculate the offset from the
start of the program header table
mov ebx,[0x1001c] ; Get the PHT offset in ebx
add ebx,eax ; Add it to our PHT entry offset
add ebx,0x10000 ; Calculate the address of the entry
cmp DWORD [ebx],1 ; Does this section have to be
loaded into memory ?
jne nextsect ; No, next section
mov DWORD ecx,[ebx+0x4] ; Get the offset of the segment
in the ELF file
mov DWORD ebp,[ebx+0x10] ; Get the size of the segment in
the ELF file
mov DWORD edi,[ebx+0x8] ; Get the memory address of the
sect.
mov DWORD eax,[ebx+0x14] ; Get the size of the section in
mov ebx,eax ; the memory into ebx
push ebp
pusha
mov esi, 0x10000
add esi, ecx
mov ecx, ebp
call memcopy
popa
pop eax
sub ebx,eax ; This amount needs to be zeroed
jz nextsect ; It's ok, next section
add edi,eax ; Zero the memory from this address
xor ax,ax ; edi is an absolute address
mov ecx,ebx
call zero_memblock ; Zero the rest of the section
nextsect:
pop cx ; Restore our section count
or cx,cx ; Was this the last one ?
jnz sectionloop
; The file is loaded into high memory, so now lets get to it
mov dword esp,0x90000 ; Have a nice big stack, that
wont interfere
mov ebp,esp ; C uses ebp as a frame pointer,
so set this equal
push DWORD 2 ; Go in with a nice clean set of
flags
popfd
mov eax, [krnl_entry] ; Our saved kernel entry point
call eax
cli ; Should never get here, but
just in case it does
hlt ; Lets just stop and hang out
hang:jmp hang ; In case of a stray interrupt
;*************************************************************************
;*************************************************************************
; 32 bit support functions
;*************************************************************************
;*************************************************************************
;*************************************************************************
; PROCEDURE zero_memblock
; Sets the memory starting at edi to zeros for a length of ecx
;*************************************************************************
zero_memblock:
push eax ; Save the registers
push edi
push ecx
xor eax,eax ; Fill the memory with zeros (0x0)
cld ; Clear the direction flag; rep
increments di
a32 rep stosb ; Fill the memory (one byte at a
time)
pop ecx
pop edi
pop eax
ret
;*************************************************************************
; PROCEDURE memcopy
; Copies data from esi to edi with length ecx
;*************************************************************************
memcopy:
pusha
memcopy_loop:
mov al, [esi]
mov [edi], al
inc edi
inc esi
loop memcopy_loop
popa
ret |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Francesco Salvestrini
Guest
|
| Posted: Fri Jul 04, 2008 12:48 am Post subject: Re: ELF image format |
|
|
BG wrote:
| Quote: |
"Francesco Salvestrini" <salvestrini@gmail.com> wrote in message
news:g4e72m$9k$1@aioe.org...
Maxim S. Shatskih wrote:
Named sections with alphabetic order?
It does not constraint the linker to place sections in alphabetical
order, look at section-names/file-offsets:
$ objdump -h src/kernel
src/kernel: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0001725c 00100000 00100000 00001000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .syscall 0000005c 00117260 00117260 00018260 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .rodata 00006b69 001172c0 001172c0 000182c0 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .gcc_except_table 0000002e 0011de2c 0011de2c 0001ee2c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .data 00000c60 0011de60 0011de60 0001ee60 2**5
CONTENTS, ALLOC, LOAD, DATA
5 .got 00000020 0011eac0 0011eac0 0001fac0 2**2
CONTENTS, ALLOC, LOAD, DATA
6 .got.plt 0000000c 0011eae0 0011eae0 0001fae0 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .bss 00009ed4 0011eb00 0011eb00 0001faec 2**5
ALLOC
8 .debug 0005cf45 001289d8 001289d8 0001faf0 2**3
CONTENTS, READONLY, DEBUGGING
9 ...
...
Cheers,
Francesco
--
Smoking Prohibited. Absolutely no ifs, ands, or butts.
Write your own link script then use it with ld like so
ld -T location/of/link/script.lds ....
In the following example, place the multiboot stuff in section ".init"
|
I've already tried that solution in the past, with different behaviours:
In the following description I'm assuming that the multiboot object is not
necessarely is the first object in the linker line, which is the degree of
freedom I'm looking for:
a) If I place a .multiboot section this way:
SECTIONS {
...
.multiboot {
... here goes the multiboot header
}
.text {
...
}
...
}
The text section came first in the elf image file, which give to me a non
multiboot compliant image.
b) If I place the multiboot header inside the .text section, the solution
works only if the .text section is the first section in the linker script
(by swapping .rodata with .text I get a non multiboot compliant image
again).
This example works:
SECTIONS {
.text {
... here goes the multiboot header
...
}
.rodata {
...
}
...
}
While the following won't work:
SECTIONS {
.rodata {
...
}
.text {
... here goes the multiboot header
...
}
...
}
Assuming that the order of sections get translated 1:1 into the image file
is not a good solution for me. The `SECTIONS' command tells the linker how
to map input sections into output sections, and how to place the output
sections in memory.
IMHO:
I think that your approach works (again: in my environment) by relying on
the linker behaviour of placing .text as first section, which is not
necessarely based on alphabetical ordering; see the "Off" and "[Nr]"
columns:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk
Inf Al
[ 0] NULL 00000000 000000 000000 00 0
0 0
[ 1] .text PROGBITS 00100000 001000 0170ec 00 AX 0
0 16
[ 2] .syscall PROGBITS 001170f0 0180f0 00005c 00 AX 0
0 16
[ 3] .rodata PROGBITS 00117160 018160 006b69 00 A 0
0 32
[ 4] .gcc_except_table PROGBITS 0011dccc 01eccc 00002e 00 A 0
0 4
[ 5] .data PROGBITS 0011dd00 01ed00 000c60 00 WA 0
0 32
[ 6] .got PROGBITS 0011e960 01f960 000020 04 WA 0
0 4
[ 7] .got.plt PROGBITS 0011e980 01f980 00000c 04 WA 0
0 4
[ 8] .bss NOBITS 0011e9a0 01f98c 00a054 00 WA 0
0 32
[ 9] .debug PROGBITS 001289f8 01f990 05d0b1 00 0
0 8
[10] .shstrtab STRTAB 00000000 07ca41 000064 00 0
0 1
[11] .symtab SYMTAB 00000000 07ccb0 005420 10 12
567 4
[12] .strtab STRTAB 00000000 0820d0 006782 00 0
0 1
...
Cheers,
Francesco
| Quote: |
-----------------------------8<-------------------------------------------------------
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(arch_entry_point)
SECTIONS
{
/*
* Set the image base pointer
*/
LINKSCRIPT_IMAGEBASE = 0x00400000;
. = 0x00400000;
/*
* The text and rodata section
*/
.text (LINKSCRIPT_IMAGEBASE) : AT(LINKSCRIPT_IMAGEBASE)
{
*(.init) /* MULTIBOOT SECTION */
*(.text)
. = ALIGN(16);
*(.rodata)
*(.rodata.*)
} = 0x9090
/*
* The data section
*/
. = ALIGN(4096); .data BLOCK(4096)
:
{
*(.data)
}
. = ALIGN(4096);
.rsrc BLOCK(4096) :
{
*(.rsrc)
}
/*
* Now for the BSS section
*/
. = ALIGN(4096);
.bss BLOCK(4096) :
{
*(.bss)
*(COMMON)
}
/*
* Sections to discard
*/
/DISCARD/ :
{
*(.text.exit)
*(.data.exit)
*(.exitcall.exit)
*(.stab)
*(.stabstr)
*(.stab.excl)
*(.stab.exclstr)
*(.stab.index)
*(.stab.indexstr)
*(.comment)
*(.note)
}
/*
* Finally, this points to the end of the image
*/
. = ALIGN(4096);
LINKSCRIPT_IMAGEEND = .;
}
|
--
Show your affection, which will probably meet with pleasant response. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Francesco Salvestrini
Guest
|
| Posted: Fri Jul 04, 2008 1:57 am Post subject: Re: ELF image format |
|
|
Kristof Benes wrote:
| Quote: |
Francesco Salvestrini wrote:
Kristof Benes wrote:
Francesco Salvestrini wrote:
Hi all,
|
....
| Quote: |
I'm looking for a solution with the less number of constraints as
possible. There are three possible solutions IMHO:
1) Place the multiboot header object first in the link line
PRO: Easy
CON1: The command line could get too long if you have too many objects to
link (use libraries/archives to solve the problem)
CON2: The solution relies on the linker behaviour and depends directly on
the linker implementation
2) Have a short (size < 8KB) multiboot compliant elf image which get
loaded by a multiboot compliant loader, the image "loads" all your
modules (the kernel is a "module" itself) afterward.
PRO: No link order necessary
CON: Needs code to dynamically load the elf "modules". If you have
dynamic loading related code already ... there should be no problems.
3) Rearrange the kernel elf structure using libbfd: scan the input kernel
elf image rearranging the sections on-the-fly, in order to have the
section containing the multiboot header at first in the output file.
PROS: No link order necessary
CONS1: The multiboot header must be placed at offset < 8KB from the
beginning of the section that must be moved on top of the elf image (a
single section containing only the multiboot header solve the problem).
CONS2: Not so easy, needs a bit-of-elf-image-format-knowledge
The last solution is the one I'm concentrating on, at the moment. Have
you a better idea ?
Thanks
Francesco
I've never delved into the world of multiboot, and the only question I
have is is the multiboot header in its own section ie not .text or
.data, but something else, like .mboot or something? If so, you could
probably relocate it with link options. For gnu ld its -Ttext=.... and
you can specify additional sections too, so like say its loaded at
0x10000, you could do -Ttext 0x10200 -Tmboot 0x10000 (assuming an 8kb
size).
|
That solution does not work for me. Instructing the linker where to place
each section in memory does not give enough constraints in the image file
layout: a section X which comes before Y in memory, won't necessarily come
in the same order in the image file ([X, Y] in memory could be [Y, X] in
the image file).
As far as I know the linker (GNU ld) chooses to place .text section as the
first section (probably due to its implementation) in the elf image file.
The remaining sections won't be placed in the elf image file in
alphabetical order (which would be a really fragile solution too).
So the only solution (which uses a linker script rearrangement) to avoid the
constraint of placing multiboot.o as the first entry in the link line is
the one which places the multiboot header in the .text section (again:
AFAIK).
The "linker script arrangement" approach works for a.out images (there is
only .text, .bss and .data so not so many tricks could be done there),
while seems too fragile in the elf realm to me (again: IMHO).
| Quote: |
Worst comes to worst you could always do "cat mboot.bin
kernel.elf > kernel.bin" and load kernel.bin . I do something similar
in mine I have 16 bit video switching code that just gets globbed onto
the front of the kernel elf itself.
|
That means that the multiboot loader doesn't look for an elf image
directly ... it looks both for the multiboot header and for the elf header:
finds the multiboot header, works on that header, finds the elf header,
works on the elf header (not necessarily in this order) ... good to know,
I'll give it a try :-)
The problem there lies probably here: you need to resolve the kernel entry
point and place it in the multiboot header.
Maybe having a small (< 8KB) multiboot compliant unpacker which finds its
supported images (a.out or elf for kernel + modules) already loaded into
memory could be a viable approach (no tricks needed there, only more code
to write and test). The elf-handling code gets replicated both in the
unpacker and in the kernel if you support dynamic loading. This is not a
great issue both for code-duplication (solved using libraries) and for
memory-space (the space used by the unpacker could be reclaimed when the
kernel starts its execution).
| Quote: |
If you want to get really ninja and modify the elf structure itself,
|
No, no ... I could become a kamikaze first, without reaching such status :-D
I'm only puzzled by the problem. I would be glad to find a viable approach
without (not-so-many) fancy workarounds ...
Thanks!
| Quote: |
Of course all of that assumes that the mboot section is in its own
section. If its in the text or data section youre screwed. Those can
be interspersed anywhere especially with optimized code. And elf
manipulation wont work under all compilers, which it sounds like you are
trying to do. DJGPP for instance uses a.out which is totally different.
Even some older versions of FreeBSD still use a.out.
|
AFAIK the section reordering could be performed if the involved sections are
not interlinked with others. A glance at libelf x.movscn.c file (note
the "nothing to do" remark):
size_t
elfx_movscn(Elf *elf, Elf_Scn *scn, Elf_Scn *after) {
Elf_Scn *prev;
Elf_Scn *tmp;
int off;
if (!elf || !scn || !after) {
return SHN_UNDEF;
}
elf_assert(elf->e_magic == ELF_MAGIC);
if (elf->e_kind != ELF_K_ELF) {
seterr(ERROR_NOTELF);
return SHN_UNDEF;
}
elf_assert(scn->s_magic == SCN_MAGIC);
elf_assert(after->s_magic == SCN_MAGIC);
if (scn->s_elf != elf || after->s_elf != elf) {
seterr(ERROR_ELFSCNMISMATCH);
return SHN_UNDEF;
}
elf_assert(elf->e_scn_1);
if (scn == elf->e_scn_1) {
seterr(ERROR_NULLSCN);
return SHN_UNDEF;
}
if (scn == after || scn == after->s_link) {
/* nothing to do */
return scn->s_index;
}
/*
* Find previous section.
*/
prev = NULL;
for (tmp = elf->e_scn_1; tmp->s_link; tmp = tmp->s_link) {
if (tmp->s_link == scn) {
prev = tmp;
break;
}
}
elf_assert(prev != NULL);
/*
* Update section indices
*/
off = 0;
for (tmp = elf->e_scn_1; tmp; tmp = tmp->s_link) {
if (off) {
tmp->s_index += off;
}
if (tmp == after) {
off++;
}
else if (tmp == scn) {
off--;
}
}
elf_assert(off == 0);
/*
* Move section.
*/
prev->s_link = scn->s_link;
scn->s_link = after->s_link;
after->s_link = scn;
scn->s_index = after->s_index + 1;
if (elf->e_scn_n == scn) {
elf->e_scn_n = prev;
}
else if (elf->e_scn_n == after) {
elf->e_scn_n = scn;
}
#if ENABLE_DEBUG
/*
* Check section indices
*/
tmp = elf->e_scn_1;
elf_assert(tmp->s_index == 0);
while (tmp->s_link) {
elf_assert(tmp->s_link->s_index == tmp->s_index + 1);
tmp = tmp->s_link;
}
#endif /* ENABLE_DEBUG */
return scn->s_index;
}
I'm not going to solve the problem of a "generic section reorder". The
problem should be simpler: I'm going to move a dedicated section (with raw
file size < 8KB) containing the multiboot header, in order to have it
appearing as the first one in the resulting image file.
| Quote: |
Most linkers, especially ones that create elf formats generally follow
the order that the object files are passed in. The few a.out linkers
I've seen do the same as well. Even Micro$oft VC++ linker uses the same
idea for its proprietary object format (PE). I'm sure there are some
compilers out there that do relocate stuff wherever it would fit best,
but they probably arent even designed for the x86 platform. So my guess
is your pretty much safe with option 1. Although it is fun to mess with
an executable file and still have it work. 
|
:-)
Thanks for links and hints
Francesco
--
Success is in the minds of Fools.
-- William Wrenshaw, 1578 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Kristof Benes
Guest
|
| Posted: Fri Jul 04, 2008 3:58 am Post subject: Re: ELF image format |
|
|
Francesco Salvestrini wrote:
| Quote: |
Kristof Benes wrote:
Francesco Salvestrini wrote:
Kristof Benes wrote:
Francesco Salvestrini wrote:
Hi all,
...
I'm looking for a solution with the less number of constraints as
possible. There are three possible solutions IMHO:
1) Place the multiboot header object first in the link line
PRO: Easy
CON1: The command line could get too long if you have too many objects to
link (use libraries/archives to solve the problem)
CON2: The solution relies on the linker behaviour and depends directly on
the linker implementation
2) Have a short (size < 8KB) multiboot compliant elf image which get
loaded by a multiboot compliant loader, the image "loads" all your
modules (the kernel is a "module" itself) afterward.
PRO: No link order necessary
CON: Needs code to dynamically load the elf "modules". If you have
dynamic loading related code already ... there should be no problems.
3) Rearrange the kernel elf structure using libbfd: scan the input kernel
elf image rearranging the sections on-the-fly, in order to have the
section containing the multiboot header at first in the output file.
PROS: No link order necessary
CONS1: The multiboot header must be placed at offset < 8KB from the
beginning of the section that must be moved on top of the elf image (a
single section containing only the multiboot header solve the problem).
CONS2: Not so easy, needs a bit-of-elf-image-format-knowledge
The last solution is the one I'm concentrating on, at the moment. Have
you a better idea ?
Thanks
Francesco
I've never delved into the world of multiboot, and the only question I
have is is the multiboot header in its own section ie not .text or
.data, but something else, like .mboot or something? If so, you could
probably relocate it with link options. For gnu ld its -Ttext=.... and
you can specify additional sections too, so like say its loaded at
0x10000, you could do -Ttext 0x10200 -Tmboot 0x10000 (assuming an 8kb
size).
That solution does not work for me. Instructing the linker where to place
each section in memory does not give enough constraints in the image file
layout: a section X which comes before Y in memory, won't necessarily come
in the same order in the image file ([X, Y] in memory could be [Y, X] in
the image file).
As far as I know the linker (GNU ld) chooses to place .text section as the
first section (probably due to its implementation) in the elf image file.
The remaining sections won't be placed in the elf image file in
alphabetical order (which would be a really fragile solution too).
So the only solution (which uses a linker script rearrangement) to avoid the
constraint of placing multiboot.o as the first entry in the link line is
the one which places the multiboot header in the .text section (again:
AFAIK).
The "linker script arrangement" approach works for a.out images (there is
only .text, .bss and .data so not so many tricks could be done there),
while seems too fragile in the elf realm to me (again: IMHO).
Worst comes to worst you could always do "cat mboot.bin
kernel.elf > kernel.bin" and load kernel.bin . I do something similar
in mine I have 16 bit video switching code that just gets globbed onto
the front of the kernel elf itself.
That means that the multiboot loader doesn't look for an elf image
directly ... it looks both for the multiboot header and for the elf header:
finds the multiboot header, works on that header, finds the elf header,
works on the elf header (not necessarily in this order) ... good to know,
I'll give it a try :-)
The problem there lies probably here: you need to resolve the kernel entry
point and place it in the multiboot header.
Maybe having a small (< 8KB) multiboot compliant unpacker which finds its
supported images (a.out or elf for kernel + modules) already loaded into
memory could be a viable approach (no tricks needed there, only more code
to write and test). The elf-handling code gets replicated both in the
unpacker and in the kernel if you support dynamic loading. This is not a
great issue both for code-duplication (solved using libraries) and for
memory-space (the space used by the unpacker could be reclaimed when the
kernel starts its execution).
If you want to get really ninja and modify the elf structure itself,
No, no ... I could become a kamikaze first, without reaching such status :-D
I'm only puzzled by the problem. I would be glad to find a viable approach
without (not-so-many) fancy workarounds ...
look at http://www.cs.ucdavis.edu/~haungs/paper/node10.html I used the
info in there to construct my elf unpacker.
Thanks!
Of course all of that assumes that the mboot section is in its own
section. If its in the text or data section youre screwed. Those can
be interspersed anywhere especially with optimized code. And elf
manipulation wont work under all compilers, which it sounds like you are
trying to do. DJGPP for instance uses a.out which is totally different.
Even some older versions of FreeBSD still use a.out.
AFAIK the section reordering could be performed if the involved sections are
not interlinked with others. A glance at libelf x.movscn.c file (note
the "nothing to do" remark):
size_t
elfx_movscn(Elf *elf, Elf_Scn *scn, Elf_Scn *after) {
Elf_Scn *prev;
Elf_Scn *tmp;
int off;
if (!elf || !scn || !after) {
return SHN_UNDEF;
}
elf_assert(elf->e_magic == ELF_MAGIC);
if (elf->e_kind != ELF_K_ELF) {
seterr(ERROR_NOTELF);
return SHN_UNDEF;
}
elf_assert(scn->s_magic == SCN_MAGIC);
elf_assert(after->s_magic == SCN_MAGIC);
if (scn->s_elf != elf || after->s_elf != elf) {
seterr(ERROR_ELFSCNMISMATCH);
return SHN_UNDEF;
}
elf_assert(elf->e_scn_1);
if (scn == elf->e_scn_1) {
seterr(ERROR_NULLSCN);
return SHN_UNDEF;
}
if (scn == after || scn == after->s_link) {
/* nothing to do */
return scn->s_index;
}
/*
* Find previous section.
*/
prev = NULL;
for (tmp = elf->e_scn_1; tmp->s_link; tmp = tmp->s_link) {
if (tmp->s_link == scn) {
prev = tmp;
break;
}
}
elf_assert(prev != NULL);
/*
* Update section indices
*/
off = 0;
for (tmp = elf->e_scn_1; tmp; tmp = tmp->s_link) {
if (off) {
tmp->s_index += off;
}
if (tmp == after) {
off++;
}
else if (tmp == scn) {
off--;
}
}
elf_assert(off == 0);
/*
* Move section.
*/
prev->s_link = scn->s_link;
scn->s_link = after->s_link;
after->s_link = scn;
scn->s_index = after->s_index + 1;
if (elf->e_scn_n == scn) {
elf->e_scn_n = prev;
}
else if (elf->e_scn_n == after) {
elf->e_scn_n = scn;
}
#if ENABLE_DEBUG
/*
* Check section indices
*/
tmp = elf->e_scn_1;
elf_assert(tmp->s_index == 0);
while (tmp->s_link) {
elf_assert(tmp->s_link->s_index == tmp->s_index + 1);
tmp = tmp->s_link;
}
#endif /* ENABLE_DEBUG */
return scn->s_index;
}
I'm not going to solve the problem of a "generic section reorder". The
problem should be simpler: I'm going to move a dedicated section (with raw
file size < 8KB) containing the multiboot header, in order to have it
appearing as the first one in the resulting image file.
Most linkers, especially ones that create elf formats generally follow
the order that the object files are passed in. The few a.out linkers
I've seen do the same as well. Even Micro$oft VC++ linker uses the same
idea for its proprietary object format (PE). I'm sure there are some
compilers out there that do relocate stuff wherever it would fit best,
but they probably arent even designed for the x86 platform. So my guess
is your pretty much safe with option 1. Although it is fun to mess with
an executable file and still have it work. :-)
:-)
More links to good ELF resources can be found in wikipedia
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
Thanks for links and hints
Francesco
So it sounds like out of all of those, the bootstrap idea seemed the |
best to you. Unpacking an elf file is a really easy task assuming its
statically linked and stripped, basically its copying text and data up
into memory and zeroing out bss. You can definitely write something to
unpack an elf into high memory in under 8kb, my second stage bootloader
tips the scales at 1081 bytes to load a file from a floppy's FAT12
filesystem, set up pmode, enable a20 (reliably), unpack the elf image
into high memory (my base is 0x100000) and start it. It actually just
loads a file named kernel.bin which has a 512 byte header (the video
code) at 0xfe00 and then goes off the assumption that the elf image
starts at 0x10000.
In the past I have gone the route of having a bootstrap in front of the
elf image and eliminated the second stage altogether, although in this
case I chose the two stage route for various other reasons outside of
this scope. And yes gnu ld does place .text first. In my kernel the
file entry.c is the first in my list of linked objects and the first
function in it is _start, and my entry point is always 0x100000. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
125 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
