search

solana-labs / rbpf

Rust virtual machine and JIT compiler for eBPF programs
Apache License 2.0
272 stars 164 forks source link

32bit target support #436

Open acheroncrypto opened 1 year ago

acheroncrypto commented 1 year ago

I would like to make interpreter work on 32bit architechtures. Currently there is no compilation error and regular programs seem to work as expected but various memory readings during syscalls like InvokeSignedRust return invalid pointers which results in program fails to complete error.

Going by the comment of

// Memory map regions virtual addresses need to be (1 << VIRTUAL_ADDRESS_BITS) bytes apart.
// Also the region at index 0 should be skipped to catch NULL ptr accesses.

I've played with some of the values like MM_PROGRAM_START and VIRTUAL_ADDRESS_BITS and got some improvements(some of the memory translations ended up being correct during syscalls) but programs still failed to complete on 32bit and worked fine on 64bit after the changes.

And what's the effect of program-runtime-v2 on this? Particularly this part https://github.com/solana-labs/solana/issues/29864:

Dynamic function calls replacing CPI and Syscalls Replace VM nesting by dynamic linking using two levels of indirection [Not MVP] Replace syscalls by CPI to built-in programs

A general advice on how to achieve this would be really helpful, thank you!

Lichtso commented 1 year ago

Is this related to compiling the Interpreter for WASM or is there a different motivation of bringing it to 32 bit? The thing is that our entire ecosystem relies on the implicit assumption of running 64bit guests on 64bit host systems. So while not impossible, it is hard to pull off and will probably not receive much attention from our side.

That being said, the memory mapping system currently in place does assume that the 64bit address space is essentially for fat pointers which are split into a 32bit region index and a 32bit address space inside each region. We also have unaligned memory mapping, so that design broke down a little.

In program runtime v2, if we manage to remove address translation, then this will be a lot easier as the host could dictate the memory layout and also address space size, thus would be able to use 32 bit pointers.

acheroncrypto commented 1 year ago

Yes, the motivation is to run programs in browsers with wasm32-unknown-unknown target as wasm64 is not ready yet.

Unfortunately, as you've said there seems to be a quite a bit of 64bit assumption of usize etc.

In program runtime v2, if we manage to remove address translation, then this will be a lot easier as the host could dictate the memory layout and also address space size, thus would be able to use 32 bit pointers.

That sounds great! All of the issues that I've run into so far with WASM seems to be caused by the address translation.