Related
I have the following 'uppercaser.asm' assembly program in NASM which converts all lowercase letters input from user into uppercase:
section .bss
Buff resb 1
section .data
section .text
global _start
_start:
nop ; This no-op keeps the debugger happy
Read: mov eax,3 ; Specify sys_read call
mov ebx,0 ; Specify File Descriptor 0: Standard Input
mov ecx,Buff ; Pass offset of the buffer to read to
mov edx,1 ; Tell sys_read to read one char from stdin
int 80h ; Call sys_read
cmp eax,0 ; Look at sys_read's return value in EAX
je Exit ; Jump If Equal to 0 (0 means EOF) to Exit
; or fall through to test for lowercase
cmp byte [Buff],61h ; Test input char against lowercase 'a'
jb Write ; If below 'a' in ASCII chart, not lowercase
cmp byte [Buff],7Ah ; Test input char against lowercase 'z'
ja Write ; If above 'z' in ASCII chart, not lowercase
; At this point, we have a lowercase character
sub byte [Buff],20h ; Subtract 20h from lowercase to give uppercase...
; ...and then write out the char to stdout
Write: mov eax,4 ; Specify sys_write call
mov ebx,1 ; Specify File Descriptor 1: Standard output
mov ecx,Buff ; Pass address of the character to write
mov edx,1 ; Pass number of chars to write
int 80h ; Call sys_write...
jmp Read ; ...then go to the beginning to get another character
Exit: mov eax,1 ; Code for Exit Syscall
mov ebx,0 ; Return a code of zero to Linux
int 80H ; Make kernel call to exit program
The program is then assembled with the -g -F stabs option for the debugger and linked for 32-bit executables in ubuntu 18.04.
Running readelf --segments uppercaser for the segments and readelf -S uppercaser for the sections I see a difference in size of text segment and text section.
readelf --segments uppercaser
Elf file type is EXEC (Executable file)
Entry point 0x8048080
There are 2 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x08048000 0x08048000 0x000db 0x000db R E 0x1000
LOAD 0x0000dc 0x080490dc 0x080490dc 0x00000 0x00004 RW 0x1000
Section to Segment mapping:
Segment Sections...
00 .text
01 .bss
readelf -S uppercaser
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 08048080 000080 00005b 00 AX 0 0 16
[ 2] .bss NOBITS 080490dc 0000dc 000004 00 WA 0 0 4
[ 3] .stab PROGBITS 00000000 0000dc 000120 0c 4 0 4
[ 4] .stabstr STRTAB 00000000 0001fc 000011 00 0 0 1
[ 5] .comment PROGBITS 00000000 00020d 00001f 00 0 0 1
[ 6] .shstrtab STRTAB 00000000 00022c 00003e 00 0 0 1
[ 7] .symtab SYMTAB 00000000 0003d4 0000f0 10 8 11 4
[ 8] .strtab STRTAB 00000000 0004c4 000045 00 0 0 1
In the sections description one can see that the size of .text section is 5Bh=91 bytes (the same number one is getting with the size command) whereas in the segments description we see that the size is 0x000DB, a difference of 128 bytes. Why is that?
From the elf man pages for the Elf32_Phdr (program header) structure:
p_filesz
This member holds the number of bytes in the file image of
the segment. It may be zero.
p_memsz
This member holds the number of bytes in the memory image
of the segment. It may be zero.
Is the difference somehow related to the .bss section?
Notice that the first program segment at file address 0 starts at virtual address 0x08048000, not at VA 0x08048080 which corresponds with the .text section.
In fact the segment displayed by readelf as 00 .text covers ELF file header (52 bytes), alignment, two program headers (2*32 bytes) and the netto contents of .text section, alltogether mapped from file address 0 to VA 0x08048000.
I was reading the arch/arm/kernel/head.S and I found some code in the __mmap_switch as following:
adr r3, __mmap_switched_data
ldmia r3!, {r4, r5, r6, r7}
cmp r4, r5 # Copy data segment if needed
1: cmpne r5, r6
ldrne fp, [r4], #4
strne fp, [r5], #4
bne 1b
mov fp, #0 # Clear BSS (and zero fp)
1: cmp r6, r7
strcc fp, [r6],#4
bcc 1b
The annotation shows that these operations work for a task(or a thread).And I got the __mmap_switch_data:
__mmap_switched_data:
.long __data_loc # r4
.long _sdata # r5
.long __bss_start # r6
.long _end # r7
.long processor_id # r4
.long __machine_arch_type # r5
.long __atags_pointer # r6
#ifdef CONFIG_CPU_CP15
.long cr_alignment # r7
#else
.long 0 # r7
#endif
.long init_thread_union + THREAD_START_SP # sp
.size __mmap_switched_data, . - __mmap_switched_data
__FINIT
.text
I know the init_thread_union is related with init_task().So are these operations allocation space for the init_task() by a static way as the memory subsystem hasn't been initialized?If it is,how can init_task() get these information?
I have the following bootloader code which seems to run perfectly fine on a hard disk:
[bits 16]
[org 0x7c00]
bootld_start:
KERNEL_OFFSET equ 0x2000
xor ax, ax ; Explicitly set ES = DS = 0
mov ds, ax
mov es, ax
mov bx, 0x8C00 ; Set SS:SP to 0x8C00:0x0000 . The stack will exist
; between 0x8C00:0x0000 and 0x8C00:0xFFFF
mov ss, bx
mov sp, ax
mov [BOOT_DRIVE], dl
mov bx, boot_msg
call print_string
mov dl, [BOOT_DRIVE]
call disk_load
jmp pm_setup
jmp $
BOOT_DRIVE:
db 0
disk_load:
mov si, dap
mov ah, 0x42
int 0x13
;cmp al, 4
;jne disk_error_132
ret
dap:
db 0x10 ; Size of DAP
db 0
; You can only read 46 sectors into memory between 0x2000 and
; 0x7C00. Don't read anymore or we overwrite the bootloader we are
; executing from. (0x7c00-0x2000)/512 = 46
dw 46 ; Number of sectors to read
dw KERNEL_OFFSET ; Offset
dw 0 ; Segment
dd 1
dd 0
disk_error_132:
mov bx, disk_error_132_msg
call print_string
jmp $
disk_error_132_msg:
db 'Error! Error! Something is VERY wrong! (0x132)', 0
gdt_start:
gdt_null:
dd 0x0
dd 0x0
gdt_code:
dw 0xffff
dw 0x0
db 0x0
db 10011010b
db 11001111b
db 0x0
gdt_data:
dw 0xffff
dw 0x0
db 0x0
db 10010010b
db 11001111b
db 0x0
gdt_end:
gdt_descriptor:
dw gdt_end - gdt_start
dd gdt_start
CODE_SEG equ gdt_code - gdt_start
DATA_SEG equ gdt_data - gdt_start
boot_msg:
db 'OS is booting files... ', 0
done_msg:
db 'Done! ', 0
%include "boot/print_string.asm"
pm_setup:
mov bx, done_msg
call print_string
mov ax, 0
mov ss, ax
mov sp, 0xFFFC
mov ax, 0
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
cli
lgdt[gdt_descriptor]
mov eax, cr0
or eax, 0x1
mov cr0, eax
jmp CODE_SEG:b32
[bits 32]
VIDEO_MEMORY equ 0xb8000
WHITE_ON_BLACK equ 0x0f
print32:
pusha
mov edx, VIDEO_MEMORY
.loop:
mov al, [ebx]
mov ah, WHITE_ON_BLACK
cmp al, 0
je .done
mov [edx], ax
add ebx, 1
add edx, 2
jmp .loop
.done:
popa
ret
b32:
mov ax, DATA_SEG
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax
; Place stack below EBDA in lower memory
mov ebp, 0x9c000
mov esp, ebp
mov ebx, pmode_msg
call print32
call KERNEL_OFFSET
jmp $
pmode_msg:
db 'Protected mode enabled!', 0
kernel:
mov ebx, pmode_msg
call print32
jmp $
pmode_tst:
db 'Testing...'
times 510-($-$$) db 0
db 0x55
db 0xAA
The problem is that when I convert it to an ISO with these commands:
mkdir iso
mkdir iso/boot
cp image.flp iso/boot/boot
xorriso -as mkisofs -R -J -c boot/bootcat \
-b boot/boot -no-emul-boot -boot-load-size 4 \
-o image.iso iso
...it fails with a triple fault. When I run it with qemu-system-i386 -boot d -cdrom os-image.iso -m 512 -d int -no-reboot -no-shutdown, it outputs (excluding useless SMM exceptions):
check_exception old: 0xffffffff new 0xd
0: v=0d e=0000 i=0 cpl=0 IP=0008:0000000000006616
pc=0000000000006616
SP=0010:000000000009bff8 env->regs[R_EAX]=0000000000000000
EAX=00000000 EBX=00007d72 ECX=00000000 EDX=000000e0
ESI=00007cb0 EDI=00000010 EBP=0009c000 ESP=0009bff8
EIP=00006616 EFL=00000083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 00007c73 00000018
IDT= 00000000 000003ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=000000e0 CCD=000001b3 CCO=ADDB
EFER=0000000000000000
check_exception old: 0xd new 0xd
1: v=08 e=0000 i=0 cpl=0 IP=0008:0000000000006616 pc=0000000000006616 SP=0010:000000000009bff8 env- >regs[R_EAX]=0000000000000000
EAX=00000000 EBX=00007d72 ECX=00000000 EDX=000000e0
ESI=00007cb0 EDI=00000010 EBP=0009c000 ESP=0009bff8
EIP=00006616 EFL=00000083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 00007c73 00000018
IDT= 00000000 000003ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=000000e0 CCD=000001b3 CCO=ADDB
EFER=0000000000000000
check_exception old: 0x8 new 0xd
Which means that I got a 0x0d (general protection fault), then a 0x08 (double fault), then it triple faulted. Why is this happening?
EDIT: I have changed the command to:
xorriso -as mkisofs -R -J -c boot/bootcat -b boot/boot.flp -o nmos.iso nmos.flp
But I am now getting the following error:
xorriso : FAILURE : Cannot find in ISO image: -boot_image ... bin_path='/boot/boot.flp'
xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE
Does anyone know what this means?
EDIT 2:
I have changed the code to read using ah=0x02 like this:
mov bx, KERNEL_OFFSET
mov ah, 0x02
mov al, 46
mov ch, 0x00
mov dh, 0x00
mov cl, 0x02
mov dl, [BOOT_DRIVE]
int 0x13
But it is still triple-faulting. Why?
I am the developer of xorriso. If image.flp is a floppy disk image
with MBR, possibly a partition table, and a filesystem, then the hint
of Michael goes to the right direction. El Torito specifies emulations
which lets the boot image file appear to the BIOS as floppy or hard disk.
The options -no-emul-boot -boot-load-size 4 causes BIOS to load the
first 2048 bytes of file image.flp and to execute them as x86 program.
Obviously a floppy image is not suitable as plain program.
According to mkisofs traditions floppy emulation is the default with
option -b. So you would just have to remove the option -no-emul-boot
from your xorriso command line in order to get the El Torito boot image
as floppy. (-boot-load-size 4 is then obsolete, too.)
The floppy image must have either 2400, or 2880, or 5760 sectors of 512
bytes, or else it will be rejected by xorriso.
Images of other sizes may be emulated as hard disks where the first
(and only) partition entry in the MBR partition table tells the size of
the disk. xorriso -as mkisofs option -hard-disk-boot chooses this emulation.
The primary cause of all the triple faults in your question really come down to the fact that your kernel isn't being loaded properly into the memory at 0x0000:0x2000. When you transfer control to this location with a JMP you end up running what happens to be in the memory region and the CPU executes until it hits an instruction that causes a fault.
Bootable CDs are strange beasts that have a number of different modes, and there are many BIOSes that boot such CDs but they too may have their own quirks. When you use -no-emul-boot with XORRISO you are requesting the disk neither be treated as a floppy nor hard disk. You could remove -no-emul-boot -boot-load-size 4 that should generate an ISO that gets treated as a floppy. The problem with that is many real BIOSes, Emulators (BOCHs and QEMU) and Virtual machines do not support Int 13h/AH=42h extended disk reads when the CD is booted using floppy emulation. You may be forced to use regular disk read via Int 13h/AH=02h.
You should be able to use extended disk reads via Int 13h/AH=42h if you use -no-emul-boot -boot-load-size 4 but it will require some changes to your bootloader. When using -no-emul-boot -boot-load-size 4 CDROMs sector sizes are 2048 bytes, not 512. This will require a bit of modification to your bootloader and kernel. The -boot-load-size 4 writes information to the ISO that informs the BIOS to read 4 512-byte chunks from the beginning of the disk image inside the ISO. The 0xaa55 boot signature is no longer needed.
If you use -no-emul-boot there is one other snag that needs to be dealt with. On the CD-ROM LBA 0 isn't where the disk image gets placed in the final ISO. The question is, how can you get the LBA where the disk image is in the ISO? You can have XORRISO write this information into a special section of the bootloader you create, and you enable this feature with -boot-info-table.
Creating the special section at the beginning of the bootloader is relatively easy. In the El Torito Specification Supplement they mention this:
EL TORITO BOOT INFORMATION TABLE
...
The format of this table is as follows; all integers are in sec-
tion 7.3.1 ("little endian") format.
Offset Name Size Meaning
8 bi_pvd 4 bytes LBA of primary volume descriptor
12 bi_file 4 bytes LBA of boot file
16 bi_length 4 bytes Boot file length in bytes
20 bi_csum 4 bytes 32-bit checksum
24 bi_reserved 40 bytes Reserved
The 32-bit checksum is the sum of all the 32-bit words in the
boot file starting at byte offset 64. All linear block addresses
(LBAs) are given in CD sectors (normally 2048 bytes).
This is talking about the 56 bytes at offset 8 of the virtual disk we create holding our bootloader. If we modify the top of your bootloader code to look like this we effectively create a blank boot information table:
start:
jmp bootld_start
times 8-($-$$) db 0 ; Pad out first 8 bytes
; Boot info table
bi_pvd dd 0
bi_file dd 0
bi_kength dd 0
bi_csum dd 0
bi_reserved times 40 db 0 ; 40 bytes reserved
When using XORRISO with -boot-info-table this table will be filled in once the ISO is generated. bi_file is the important piece of information we will need since it is the LBA where our disk image is placed inside the ISO. We can use this to fill in the Disk Access Packet used by extended disk reads to read from the proper location of the ISO.
To make the DAP a little more readable and to account for 2048 byte sectors I've amended it to look like:
dap:
dap_size: db 0x10 ; Size of DAP
dap_zero db 0
; You can only read 11 2048 byte sectors into memory between 0x2000 and
; 0x7C00. Don't read anymore or we overwrite the bootloader we are
; executing from. (0x7c00-0x2000)/2048 = 11 (rounded down)
dap_numsec: dw 11 ; Number of sectors to read
dap_offset: dw KERNEL_OFFSET ; Offset
dap_segment: dw 0 ; Segment
dap_lba_low: dd 0
dap_lba_high:dd 0
One issue is that the LBA placed into the Boot Information table is from the start of the disk image (sector with our bootloader). We need to increment that LBA by 1 and place it into the DAP so we are using the LBA where our kernel starts. Using 32-bit instruction we can just read the 32-bit value from the Boot Information Table, add 1 and save it to the DAP. If using strictly 16-bit instructions add one to a 32-bit value is more complex. Since we are going into 386 protected mode we can assume instruction with 32-bit operands are supported in real mode. The code to update the DAP with the LBA of the kernel could look like:
mov ebx, [bi_file] ; Get LBA of our disk image in ISO
inc ebx ; Add sector to get LBA for start of kernel
mov [dap_lba_low], ebx ; Update DAP with LBA of kernel in the ISO
The only other issue is that the bootloader sector needs to be padded out to 2048 (the size of a CD-ROM sector) rather than 512 and we can remove the boot signature. Change:
times 510-($-$$) db 0
db 0x55
db 0xAA
To:
times 2048-($-$$) db 0
The modified bootloader code could look like:
[bits 16]
[org 0x7c00]
KERNEL_OFFSET equ 0x2000
start:
jmp bootld_start
times 8-($-$$) db 0 ; Pad out first 8 bytes
; Boot info table
bi_pvd dd 0
bi_file dd 0
bi_kength dd 0
bi_csum dd 0
bi_reserved times 40 db 0 ; 40 bytes reserved
bootld_start:
xor ax, ax ; Explicitly set ES = DS = 0
mov ds, ax
mov es, ax
mov bx, 0x8C00 ; Set SS:SP to 0x8C00:0x0000 . The stack will exist
; between 0x8C00:0x0000 and 0x8C00:0xFFFF
mov ss, bx
mov sp, ax
mov ebx, [bi_file] ; Get LBA of our disk image in ISO
inc ebx ; Add sector to get LBA for start of kernel
mov [dap_lba_low], ebx ; Update DAP with LBA of kernel in the ISO
mov [BOOT_DRIVE], dl
mov bx, boot_msg
call print_string
mov dl, [BOOT_DRIVE]
call disk_load
jmp pm_setup
jmp $
BOOT_DRIVE:
db 0
disk_load:
mov si, dap
mov ah, 0x42
int 0x13
;cmp al, 4
;jne disk_error_132
ret
dap:
dap_size: db 0x10 ; Size of DAP
dap_zero db 0
; You can only read 11 2048 byte sectors into memory between 0x2000 and
; 0x7C00. Don't read anymore or we overwrite the bootloader we are
; executing from. (0x7c00-0x2000)/2048 = 11 (rounded down)
dap_numsec: dw 11 ; Number of sectors to read
dap_offset: dw KERNEL_OFFSET ; Offset
dap_segment: dw 0 ; Segment
dap_lba_low: dd 0
dap_lba_high:dd 0
disk_error_132:
mov bx, disk_error_132_msg
call print_string
jmp $
disk_error_132_msg:
db 'Error! Error! Something is VERY wrong! (0x132)', 0
gdt_start:
gdt_null:
dd 0x0
dd 0x0
gdt_code:
dw 0xffff
dw 0x0
db 0x0
db 10011010b
db 11001111b
db 0x0
gdt_data:
dw 0xffff
dw 0x0
db 0x0
db 10010010b
db 11001111b
db 0x0
gdt_end:
gdt_descriptor:
dw gdt_end - gdt_start
dd gdt_start
CODE_SEG equ gdt_code - gdt_start
DATA_SEG equ gdt_data - gdt_start
boot_msg:
db 'OS is booting files... ', 0
done_msg:
db 'Done! ', 0
%include "boot/print_string.asm"
pm_setup:
mov bx, done_msg
call print_string
mov ax, 0
mov ss, ax
mov sp, 0xFFFC
mov ax, 0
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
cli
lgdt[gdt_descriptor]
mov eax, cr0
or eax, 0x1
mov cr0, eax
jmp CODE_SEG:b32
[bits 32]
VIDEO_MEMORY equ 0xb8000
WHITE_ON_BLACK equ 0x0f
print32:
pusha
mov edx, VIDEO_MEMORY
.loop:
mov al, [ebx]
mov ah, WHITE_ON_BLACK
cmp al, 0
je .done
mov [edx], ax
add ebx, 1
add edx, 2
jmp .loop
.done:
popa
ret
b32:
mov ax, DATA_SEG
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax
; Place stack below EBDA in lower memory
mov ebp, 0x9c000
mov esp, ebp
mov ebx, pmode_msg
call print32
call KERNEL_OFFSET
jmp $
pmode_msg:
db 'Protected mode enabled!', 0
kernel:
mov ebx, pmode_msg
call print32
jmp $
pmode_tst:
db 'Testing...'
times 2048-($-$$) db 0
You can then modify your original XORRISO command to be:
xorriso -as mkisofs -R -J -c boot/bootcat \
-b boot/boot -no-emul-boot -boot-load-size 4 \
-boot-info-table -o image.iso iso
Background
"OS": Stripped down Linux, very customized, no internet access (no yum, apt-get, etc)
Kernel: 2.6.19.1
Target: 32-bit, armv5te
Current LibC: 2.3.6
Target LibC: 2.6.1
Issue
Received an .ipk from a 3rd party vendor containing an updated version of glibc. Started by investigating the compatibility of the shared objects contained within the .ipk package by placing them on the target platform and attempting to run the ld-2.6.1.so directly (chose this library because my understanding is that it has no dynamic linking to other objects).
Running this shared object library directly results in "Illegal Instruction". My initial thought was that ld was built for the wrong architecture, however, review of the readelf output appears to indicate it was set up correctly:
[root#blg_g34_z2_03 lib]# readelf -a ld-2.6.1.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: ARM
Version: 0x1
Entry point address: 0x800
Start of program headers: 52 (bytes into file)
Start of section headers: 116488 (bytes into file)
Flags: 0x4000002, has entry point, Version4 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 26
Section header string table index: 25
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .hash HASH 000000f4 0000f4 0000c4 04 A 3 0 4
[ 2] .gnu.hash GNU_HASH 000001b8 0001b8 0000e0 04 A 3 0 4
[ 3] .dynsym DYNSYM 00000298 000298 0001e0 10 A 4 3 4
[ 4] .dynstr STRTAB 00000478 000478 0001ac 00 A 0 0 1
[ 5] .gnu.version VERSYM 00000624 000624 00003c 02 A 3 0 2
[ 6] .gnu.version_d VERDEF 00000660 000660 00005c 00 A 4 3 4
[ 7] .rel.dyn REL 000006bc 0006bc 0000b8 08 A 3 0 4
[ 8] .rel.plt REL 00000774 000774 000030 08 A 3 9 4
[ 9] .plt PROGBITS 000007a4 0007a4 00005c 04 AX 0 0 4
[10] .text PROGBITS 00000800 000800 017324 00 AX 0 0 16
[11] __libc_freeres_fn PROGBITS 00017b24 017b24 000148 00 AX 0 0 4
[12] .rodata PROGBITS 00017c6c 017c6c 003828 00 A 0 0 4
[13] .ARM.extab PROGBITS 0001b494 01b494 000048 00 A 0 0 4
[14] .ARM.exidx ARM_EXIDX 0001b4dc 01b4dc 000078 00 AL 10 0 4
[15] .eh_frame_hdr PROGBITS 0001b554 01b554 00001c 00 A 0 0 4
[16] .eh_frame PROGBITS 0001b570 01b570 00007c 00 A 0 0 4
[17] .data.rel.ro PROGBITS 00023db0 01bdb0 000194 00 WA 0 0 8
[18] .dynamic DYNAMIC 00023f44 01bf44 0000b8 08 WA 4 0 4
[19] .got PROGBITS 00024000 01c000 00005c 04 WA 0 0 4
[20] .data PROGBITS 00024060 01c060 000580 00 WA 0 0 8
[21] __libc_subfreeres PROGBITS 000245e0 01c5e0 000004 00 WA 0 0 4
[22] .bss NOBITS 000245e4 01c5e4 0000e4 00 WA 0 0 4
[23] .ARM.attributes ARM_ATTRIBUTES 00000000 01c5e4 000019 00 0 0 1
[24] .gnu_debuglink PROGBITS 00000000 01c5fd 000010 00 0 0 1
[25] .shstrtab STRTAB 00000000 01c60d 0000f8 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x01b4dc 0x0001b4dc 0x0001b4dc 0x00078 0x00078 R 0x4
LOAD 0x000000 0x00000000 0x00000000 0x1b5ec 0x1b5ec R E 0x8000
LOAD 0x01bdb0 0x00023db0 0x00023db0 0x00834 0x00918 RW 0x8000
DYNAMIC 0x01bf44 0x00023f44 0x00023f44 0x000b8 0x000b8 RW 0x4
GNU_EH_FRAME 0x01b554 0x0001b554 0x0001b554 0x0001c 0x0001c R 0x4
GNU_RELRO 0x01bdb0 0x00023db0 0x00023db0 0x00250 0x00250 R 0x1
Section to Segment mapping:
Segment Sections...
00 .ARM.exidx
01 .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .rel.dyn .rel.plt .plt .text __libc_freeres_fn .rodata .ARM.extab .ARM.exidx .eh_frame_hdr .eh_frame
02 .data.rel.ro .dynamic .got .data __libc_subfreeres .bss
03 .dynamic
04 .eh_frame_hdr
05 .data.rel.ro .dynamic
Dynamic section at offset 0x1bf44 contains 19 entries:
Tag Type Name/Value
0x0000000e (SONAME) Library soname: [ld-linux.so.3]
0x00000004 (HASH) 0xf4
0x6ffffef5 (GNU_HASH) 0x1b8
0x00000005 (STRTAB) 0x478
0x00000006 (SYMTAB) 0x298
0x0000000a (STRSZ) 428 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x24000
0x00000002 (PLTRELSZ) 48 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x774
0x00000011 (REL) 0x6bc
0x00000012 (RELSZ) 184 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffc (VERDEF) 0x660
0x6ffffffd (VERDEFNUM) 3
0x6ffffff0 (VERSYM) 0x624
0x6ffffffa (RELCOUNT) 20
0x00000000 (NULL) 0x0
Relocation section '.rel.dyn' at offset 0x6bc contains 23 entries:
Offset Info Type Sym.Value Sym. Name
00023e8c 00000017 R_ARM_RELATIVE
00023e90 00000017 R_ARM_RELATIVE
00023e94 00000017 R_ARM_RELATIVE
00023e98 00000017 R_ARM_RELATIVE
00023e9c 00000017 R_ARM_RELATIVE
00023ea0 00000017 R_ARM_RELATIVE
00023ea4 00000017 R_ARM_RELATIVE
00023ea8 00000017 R_ARM_RELATIVE
00024024 00000017 R_ARM_RELATIVE
00024028 00000017 R_ARM_RELATIVE
00024030 00000017 R_ARM_RELATIVE
00024038 00000017 R_ARM_RELATIVE
0002403c 00000017 R_ARM_RELATIVE
00024040 00000017 R_ARM_RELATIVE
00024044 00000017 R_ARM_RELATIVE
00024048 00000017 R_ARM_RELATIVE
0002404c 00000017 R_ARM_RELATIVE
00024050 00000017 R_ARM_RELATIVE
00024054 00000017 R_ARM_RELATIVE
000245e0 00000017 R_ARM_RELATIVE
0002402c 00001b15 R_ARM_GLOB_DAT 00023f0c __stack_chk_guard
00024034 00001815 R_ARM_GLOB_DAT 00014c84 malloc
00024058 00000b15 R_ARM_GLOB_DAT 000246b4 _r_debug
Relocation section '.rel.plt' at offset 0x774 contains 6 entries:
Offset Info Type Sym.Value Sym. Name
0002400c 00000e16 R_ARM_JUMP_SLOT 00014b50 __libc_memalign
00024010 00001816 R_ARM_JUMP_SLOT 00014c84 malloc
00024014 00001016 R_ARM_JUMP_SLOT 00014d38 calloc
00024018 00000916 R_ARM_JUMP_SLOT 00014c90 realloc
0002401c 00000716 R_ARM_JUMP_SLOT 000086d4 _dl_cache_libcmp
00024020 00000816 R_ARM_JUMP_SLOT 00014b08 free
Unwind table index '.ARM.exidx' at offset 0x1b4dc contains 15 entries:
0x8ed4: 0x80b0b0b0
Compact model index: 0
0xb0 finish
0xb0 finish
0xb0 finish
0x8f0c: 0x8000abb0
Compact model index: 0
0x00 vsp = vsp + 4
0xab pop {r4, r5, r6, r7, r14}
0xb0 finish
0x8ff0: 0x8000abb0
Compact model index: 0
0x00 vsp = vsp + 4
0xab pop {r4, r5, r6, r7, r14}
0xb0 finish
0x91b0: 0x800eafb0
Compact model index: 0
0x0e vsp = vsp + 60
0xaf pop {r4, r5, r6, r7, r8, r9, r10, r11, r14}
0xb0 finish
0x9574: #0x1b494
Compact model index: 1
0x9b vsp = r11
0x49 vsp = vsp - 40
0x86 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r13, r14}
0xb0 finish
0xb0 finish
0xcf44: 0x800aafb0
Compact model index: 0
0x0a vsp = vsp + 44
0xaf pop {r4, r5, r6, r7, r8, r9, r10, r11, r14}
0xb0 finish
0xd060: 0x8014afb0
Compact model index: 0
0x14 vsp = vsp + 84
0xaf pop {r4, r5, r6, r7, r8, r9, r10, r11, r14}
0xb0 finish
0xd5c0: 0x8006afb0
Compact model index: 0
0x06 vsp = vsp + 28
0xaf pop {r4, r5, r6, r7, r8, r9, r10, r11, r14}
0xb0 finish
0x15380: #0x1b4a0
Compact model index: 1
0x01 vsp = vsp + 8
0x80 0x08 pop {r7}
0xb1 0x0e pop {r1, r2, r3}
0xb0 finish
0x158c0: #0x1b4ac
Compact model index: 1
0x02 vsp = vsp + 12
0xb1 0x0f pop {r0, r1, r2, r3}
0x8f 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r13, r14, r15}
0xb0 finish
0x158d8: #0x1b4b8
Compact model index: 1
0x07 vsp = vsp + 32
0xb1 0x0f pop {r0, r1, r2, r3}
0x8f 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r13, r14, r15}
0xb0 finish
0x158e8: #0x1b4c4
Compact model index: 1
0x29 vsp = vsp + 168
0xb1 0x0f pop {r0, r1, r2, r3}
0x8f 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r13, r14, r15}
0xb0 finish
0x158f8: #0x1b4d0
Compact model index: 1
0x27 vsp = vsp + 160
0xb1 0x0f pop {r0, r1, r2, r3}
0x8f 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r13, r14, r15}
0xb0 finish
0x1704c: 0x8004afb0
Compact model index: 0
0x04 vsp = vsp + 20
0xaf pop {r4, r5, r6, r7, r8, r9, r10, r11, r14}
0xb0 finish
0x17580: 0x8002afb0
Compact model index: 0
0x02 vsp = vsp + 12
0xaf pop {r4, r5, r6, r7, r8, r9, r10, r11, r14}
0xb0 finish
Symbol table '.dynsym' contains 30 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000800 0 SECTION LOCAL DEFAULT 10
2: 00023db0 0 SECTION LOCAL DEFAULT 17
3: 000103d4 44 FUNC GLOBAL DEFAULT 10 _dl_get_tls_static_info##GLIBC_PRIVATE
4: 00023f10 4 OBJECT GLOBAL DEFAULT 17 __pointer_chk_guard##GLIBC_PRIVATE
5: 00000000 0 OBJECT GLOBAL DEFAULT ABS GLIBC_PRIVATE
6: 00000000 0 OBJECT GLOBAL DEFAULT ABS GLIBC_2.4
7: 000086d4 260 FUNC GLOBAL DEFAULT 10 _dl_cache_libcmp##GLIBC_PRIVATE
8: 00014b08 72 FUNC WEAK DEFAULT 10 free##GLIBC_2.4
9: 00014c90 168 FUNC WEAK DEFAULT 10 realloc##GLIBC_2.4
10: 00010ed8 40 FUNC GLOBAL DEFAULT 10 _dl_allocate_tls##GLIBC_PRIVATE
11: 000246b4 20 OBJECT GLOBAL DEFAULT 22 _r_debug##GLIBC_2.4
12: 00023f3c 4 OBJECT GLOBAL DEFAULT 17 __libc_stack_end##GLIBC_2.4
13: 0001063c 160 FUNC GLOBAL DEFAULT 10 _dl_tls_get_addr_soft##GLIBC_PRIVATE
14: 00014b50 308 FUNC WEAK DEFAULT 10 __libc_memalign##GLIBC_2.4
15: 00010920 192 FUNC GLOBAL DEFAULT 10 _dl_deallocate_tls##GLIBC_PRIVATE
16: 00014d38 92 FUNC WEAK DEFAULT 10 calloc##GLIBC_2.4
17: 000245e4 4 OBJECT GLOBAL DEFAULT 22 _dl_argv##GLIBC_PRIVATE
18: 0000f474 1384 FUNC GLOBAL DEFAULT 10 _dl_mcount##GLIBC_2.4
19: 0001117c 204 FUNC GLOBAL DEFAULT 10 _dl_tls_setup##GLIBC_PRIVATE
20: 0000e598 4 FUNC GLOBAL DEFAULT 10 _dl_debug_state##GLIBC_PRIVATE
21: 00024060 1408 OBJECT GLOBAL DEFAULT 20 _rtld_global##GLIBC_PRIVATE
22: 00010ce4 272 FUNC GLOBAL DEFAULT 10 __tls_get_addr##GLIBC_2.4
23: 00011404 188 FUNC GLOBAL DEFAULT 10 _dl_make_stack_executable##GLIBC_PRIVATE
24: 00014c84 12 FUNC WEAK DEFAULT 10 malloc##GLIBC_2.4
25: 000106dc 540 FUNC GLOBAL DEFAULT 10 _dl_allocate_tls_init##GLIBC_PRIVATE
26: 00023db0 264 OBJECT GLOBAL DEFAULT 17 _rtld_global_ro##GLIBC_PRIVATE
27: 00023f0c 4 OBJECT GLOBAL DEFAULT 17 __stack_chk_guard##GLIBC_2.4
28: 00023f38 4 OBJECT GLOBAL DEFAULT 17 __libc_enable_secure##GLIBC_PRIVATE
29: 00007bc0 456 FUNC GLOBAL DEFAULT 10 _dl_rtld_di_serinfo##GLIBC_PRIVATE
Histogram for bucket list length (total of 17 buckets):
Length Number % of total Coverage
0 2 ( 11.8%)
1 6 ( 35.3%) 22.2%
2 6 ( 35.3%) 66.7%
3 3 ( 17.6%) 100.0%
Histogram for `.gnu.hash' bucket list length (total of 17 buckets):
Length Number % of total Coverage
0 2 ( 11.8%)
1 8 ( 47.1%) 29.6%
2 3 ( 17.6%) 51.9%
3 3 ( 17.6%) 85.2%
4 1 ( 5.9%) 100.0%
Version symbols section '.gnu.version' contains 30 entries:
Addr: 0000000000000624 Offset: 0x000624 Link: 3 (.dynsym)
000: 0 (*local*) 0 (*local*) 0 (*local*) 3 (GLIBC_PRIVATE)
004: 3 (GLIBC_PRIVATE) 3 (GLIBC_PRIVATE) 2 (GLIBC_2.4) 3 (GLIBC_PRIVATE)
008: 2 (GLIBC_2.4) 2 (GLIBC_2.4) 3 (GLIBC_PRIVATE) 2 (GLIBC_2.4)
00c: 2 (GLIBC_2.4) 3 (GLIBC_PRIVATE) 2 (GLIBC_2.4) 3 (GLIBC_PRIVATE)
010: 2 (GLIBC_2.4) 3 (GLIBC_PRIVATE) 2 (GLIBC_2.4) 3 (GLIBC_PRIVATE)
014: 3 (GLIBC_PRIVATE) 3 (GLIBC_PRIVATE) 2 (GLIBC_2.4) 3 (GLIBC_PRIVATE)
018: 2 (GLIBC_2.4) 3 (GLIBC_PRIVATE) 3 (GLIBC_PRIVATE) 2 (GLIBC_2.4)
01c: 3 (GLIBC_PRIVATE) 3 (GLIBC_PRIVATE)
Version definition section '.gnu.version_d' contains 3 entries:
Addr: 0x0000000000000660 Offset: 0x000660 Link: 4 (.dynstr)
000000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: ld-linux.so.3
0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GLIBC_2.4
0x0038: Rev: 1 Flags: none Index: 3 Cnt: 2 Name: GLIBC_PRIVATE
0x0054: Parent 1: GLIBC_2.4
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5TE"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
My next thought was that I know glibc provides an interface to the kernel, so perhaps it was expecting a kernel version different from 2.6.19.1. However I am not sure how to determine what version of the kernel ld is targeting.
I can post more information as its requested, open to any and all ideas. Thanks in advance.
My next thought was that I know glibc provides an interface to the kernel, so perhaps it was expecting a kernel version different from 2.6.19.1. However I am not sure how to determine what version of the kernel ld is targeting.
You can find out what kernel this build requires with readelf -n libc.so.6, which will produce something like:
Notes at offset 0x00000254 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.15 <--- this is the minimal kernel version
That said, the ld-linux should not crash with SIGILL when running on a too-old kernel. It actually tried to execute illegal instruction, and your next step should be to try to figure out which instruction that is.
gdb ./ld-2.6.1.so
(gdb) run
... wait for SIGILL
(gdb) x/i $pc <--- this will show the instruction causing SIGILL
(gdb) where <--- this will show how you got to that instruction.
Running this shared object library directly
Does any other dynamically linked binary work on this system when using this build of GLIBC?
While running ld-linux directly should work, it's not how it normally runs, so if everything else works fine, maybe you don't actually have a problem.
I use nasm to study assembly. Below is the source code:
[BITS 32]
mov ebx, 0
mov bx, 0
mov bl, 0
then I use 'ndisasm -b 32 test.bin' to get output as following:
00000000 BB00000000 mov ebx,0x0
00000005 66BB0000 mov bx,0x0
00000009 B300 mov bl,0x0
My question is the difference of BB00000000 and 66BB0000, I know the opcode of MOV is B, but what is the 66 before B?
0x66 is operand-size override prefix which means that if the default operand size is 32-bit (as your case is), it becomes 16-bit a the opcode works on 16-bit size registers (bx in your case)