Re: Update on rlbox wasm sandbox crashes
On 10/7/25 6:34 pm, John Ogness wrote:
Hi Damien,
Thanks for providing these insights!
Happy to share. :-)
It seems to me that this is where the big-endian/browser community
should be focussing its efforts: wasm2c generating portable code.
John Ogness
After testing it I agree. It really is a multi layered approach to
isolation with it being compiled to a virtual binary, decompiled into C
and then wrapped in another software layer before being compiled again.
The issue here being the virtual binary in the middle designed for an
opposite endian.
On that note, last night I confirmed my suspicions were correct. I found
an issue with a data table related to some stdout handle. It stores
stdout as some offset which acts an address in the isolated memory space
that points to this table. Later it reads from the table at that offset
and because the table is opposite endian the values are all backwards. I
just confirmed on x64 from same routine that a $05000000 is meant to be
a $05. I don't know why it insists on writing tables as bytes as if
trying to hide data. But if it just included the scalar data as a normal
array or struct, with the value it is supposed to have, it would avoid
all this endian hacking and would work normally. :-?
Given the macro reverses the same table, I wonder of they meant to
convert the table to host endian, but made an amusing blunder of
swapping the whole table instead of each scalar? So either the table
needs to be fully converted with knowledge of each scalar size. Or table
reference routines need to swap on the spot. That's what I'm thinking.
If the endian issues are isolated to this table and wasm2c knows what's
in it this will be a lot easier to fix. :-)
--
My regards,
Damien Stewart.
Reply to: