Tag: cpp

Categories
advpi

advpi – Week 6 – Code Execution

This week was hyper-focused on getting normal, proper code execution.

Code layout

The first thing to get right was the code execution.

I found this wonderful project kvm-arm32-on-arm64 that provided a style for doing this.

So, it turns out that ARM converter prints the code in the format its in memory. So, to write it correct, I used the big endian format and then stored it in code in the uint32_t format. This way, the compiler will set it to little endian format as required, and I don’t need to think about endianness for a while.

So if I take this bit of ARM code, that loops,

nop
nop
nop
mov r0,0x0
mov r1,0x1000
mov r2,0x1
add r3,r1,r2
str r3,[r1]
mov r15,0x2000000

We convert it to the following array.

uint32_t CODE[] = {
    0xE320F000,
    0xE320F000,
    0xE320F000,
    0xE3A00000,
    0xE3A01A01,
    0xE3A02001,
    0xE0813002,
    0xE5813000,
    0xE3A0F402,
};

I would expect it to exit from MMIO (as it attempts to write to a read only page) at 0x1000, and exit per the program. If it loops or does anything else, something is wrong.

Thankfully, we get this wonderful(ly confusing) output:

Hello, from advpi!
Opened bios
Attempted mmio
Attempted write=yes of value=4097 and at address=4096
Register(0)=0
Register(1)=0
Register(2)=0
Register(3)=0
Register(4)=0
Register(5)=0
Register(6)=0
Register(7)=0
Register(8)=0
Register(9)=0
Register(10)=0
Register(11)=0
Register(12)=0
Register(13)=0
Register(14)=0
Register(15)=0
Closing the Virtual Machine

So, the MMIO output was correct, but we’re not able to see the registers. I’m thinking it is more related to the exception levels and register banks that are available, but I shall check more on it as required.

So although technically we can’t see the registers, we can get some rudimentary output through MMIO, or shared memory.

If I remove the MMIO causing statement, we get an endless loop – showing that we’re stopping as required.

What’s next

This week was short as well. Following this, I’ll be setting up a GBA cart, and the video device. I’m thinking of using SDL2 to show a video device and handle device I/O.

Categories
advpi

advpi – Week 3,4,5 – Mapping the BIOS and shifting to C++

This week was a non-amusing transfer from C to C++ and adding the GBA BIOS.

BIOS Map

The Nintendo BIOS contains the basic code needed to initalize and use the GBA. After that the BIOS hands over control to the game that’s plugged in. My initial thought was to load the file into the game, then I remembered the golden word which haunted me last week – mmap. It was used to create the memory which is mapped to the guest VM.

So, I mmap-ed the BIOS file into the memory, then added it in.

void* biosRom =
        mmap(0, BIOS_SIZE, PROT_READ | PROT_EXEC, MAP_SHARED, biosFd, 0);

Now its upto the kernel to manage it, and not my headache (for now).

Then I tried mapping the BIOS into the memory of the VM, and it segfaulted instantly. I changed some of the parameters to allow writes, and then it didn’t segfault, but the mmap didn’t go through.

After looking into the documentation, here’s the mistake I was mapping.

    struct kvm_userspace_memory_region memory_region = {
        .slot = 0,
        .userspace_addr = (unsigned long long)gbaMemory->onboardMemory,
        .guest_phys_addr = 0x02000000,
        .memory_size = ONBOARD_MEM_SIZE};

I was setting the slot to 0 for both the onboard memory (or where I was putting my code), and the BIOS page. They are actually different slots of memory, and need to be initialized as separate slots.

C++

I’m not used to C (and KVM and any of this) and it shows, so its probably a good idea to shift to C++ while I still can.

I wanted exceptions to handle unexpected failures, but I also didn’t want to model for releasing resources – a job better left for the compiler. C++ seems to be a better idea. I removed all the GOTOs, and got around to C++, then finally put an exception that helped me with my sanity.

class InitializationError : public std::exception {
    private:
    std::string message;
    public:
    InitializationError(std::string);
};

Being able to use exceptions along with constructors is useful. I’m aware that there’s a performance penalty, but it should be fine as long as I spend minimal time processing in my code (the kernel handles running the guest VM, not my code).

What’s next

The registers are still seemingly useful and garbage at the same time, but we shall see. Next week will mostly be travel and continued refactoring while I try to learn more, so next week will be week 5 essentially.