Start X86_64 Code on X86 (32Bit) Linux, Running on X86_64 Cpu

Start x86_64 code on x86 (32bit) Linux, running on x86_64 CPU

You won't be able to run x86_64 programs on a 32bit kernel without some form of emulation. (The other way around works just fine though, with no emulation.)

To be able to run 64bit code on x86_64, you have to enter "long mode" which requires the appropriate page tables to be set up (among other things). A 32bit kernel won't have done any 64bit page tables or mappings. So userspace code can't enter 64bit mode. It might be possible with some kernel help, but a 32bit kernel is simply not prepared for that kind of thing.

And since you can run 32bit code just fine with a 64bit kernel, there is no real reason not to use a 64bit kernel these days, especially if you have some code that could benefit from 64bit mode (more registers in particular).

Why don't you just boot from a 64bit live-cd? Or install a 64bit distribution on a separate disk or partition?

Switch from 32bit mode to 64 bit (long mode) on 64bit linux

Contrary to the other answers, I assert that in principle the short answer is YES. This is likely not supported officially in any way, but it appears to work. At the end of this answer I present a demo.

On Linux-x86_64, a 32 bit (and X32 too, according to GDB sources) process gets CS register equal to 0x23 — a selector of 32-bit ring 3 code segment defined in GDT (its base is 0). And 64 bit processes get another selector: 0x33 — a selector of long mode (i.e. 64 bit) ring 3 code segment (bases for ES, CS, SS, DS are treated unconditionally as zeros in 64 bit mode). Thus if we do far jump, far call or something similar with target segment selector of 0x33, we'll load the corresponding descriptor to the shadow part of CS and will end up in a 64 bit segment.

The demo at the bottom of this answer uses jmp far instruction to jump to 64 bit code. Note that I've chosen a special constant to load into rax, so that for 32 bit code that instruction looks like

dec eax
mov eax, 0xfafafafa
ud2
cli ; these two are unnecessary, but leaving them here for fun :)
hlt

This must fail if we execute it having 32 bit descriptor in CS shadow part (will raise SIGILL on ud2 instruction).

Now here's the demo (compile it with fasm).

format ELF executable
segment readable executable

SYS_EXIT_32BIT=1
SYS_EXIT_64BIT=60
SYS_WRITE=4
STDERR=2

entry $
    mov ax,cs
    cmp ax,0x23 ; 32 bit process on 64 bit kernel has this selector in CS
    jne kernelIs32Bit
    jmp 0x33:start64 ; switch to 64-bit segment
start64:
use64
    mov rax, qword 0xf4fa0b0ffafafafa ; would crash inside this if executed as 32 bit code
    xor rdi,rdi
    mov eax, SYS_EXIT_64BIT
    syscall
    ud2

use32
kernelIs32Bit:
    mov edx, msgLen
    mov ecx, msg
    mov ebx, STDERR
    mov eax, SYS_WRITE
    int 0x80
    dec ebx
    mov eax, SYS_EXIT_32BIT
    int 0x80
msg:
    db "Kernel appears to be 32 bit, can't jump to long mode segment",10
msgLen = $-msg

What does x86-64 linux kernel do when it needs to run x86-32 program?

What other job does the kernel have to do to run x86-32 program?

All 64-bit parameters need to be split (e.g. passed in edx:eax instead of just rax). The mechanism used to call the kernel API is completely different (int 0x80 vs. syscall). The stack layout (which matters for things like sending signals back to user-space signal handlers) is different. Virtual memory management has to be aware that user-space can't use 64-bit pointers. Different segment registers are used for TLS (gs for 32-bit, fs for 64-bit).

Mostly it's different enough that that you end up with completely separate system call entry/exit and dispatch code (where both interfaces call the same internal functions after parameters and calling conventions are handled).

How can i emulate an x86 32 bits program on an ARM host?

x86_64-linux-gnux32-gcc is not what you want for building 32-bit programs. This is actually a 64-bit compiler that targets the x32 ABI, a scheme to have 64-bit code that needs only 32 bits for pointers. It never really caught on and is fairly obscure these days, so I'm not surprised that qemu wouldn't support it.

The x86_64 target of gcc supports building 32-bit programs as well, using the -m32 option. So you ought to be able to build your 32-bit Hello World with

x86_64-linux-gnu-gcc test1.c -o test1_32 -m32

(You might have to separately install 32-bit x86 libraries to successfully cross compile.)

Then to run it, use qemu-i386 instead of qemu-x86_64.

Running 32 bit assembly code on a 64 bit Linux & 64 bit Processor : Explain the anomaly

Remember that everything by default on a 64-bit OS tends to assume 64-bit. You need to make sure that you are (a) using the 32-bit versions of your #includes where appropriate (b) linking with 32-bit libraries and (c) building a 32-bit executable. It would probably help if you showed the contents of your makefile if you have one, or else the commands that you are using to build this example.

FWIW I changed your code slightly (_start -> main):

#include <asm/unistd.h>
#include <syscall.h>
#define STDOUT 1

    .data
hellostr:
    .ascii "hello wolrd\n" ;
helloend:

    .text
    .globl main

main:
    movl $(SYS_write) , %eax  //ssize_t write(int fd, const void *buf, size_t count);
    movl $(STDOUT) , %ebx
    movl $hellostr , %ecx
    movl $(helloend-hellostr) , %edx
    int $0x80

    movl $(SYS_exit), %eax //void _exit(int status);
    xorl %ebx, %ebx
    int $0x80

    ret

and built it like this:

$ gcc -Wall test.S -m32 -o test

verfied that we have a 32-bit executable:

$ file test
test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped

and it appears to run OK:

$ ./test
hello wolrd

---

Related Topics