[Solved] FFI Safety?

[qwdqwqwffqw]

Hi. I'm currently trying to improve performance and memory usage on my game by using C data structures instead of lua tables.

I am not talking about security problems from malicious codes or anything like that, but about what the mistakes in code writing data on memory might cause on the machine itself.

Is worst thing that can happen is game crashing without any warning? Or some lasting problems like messing up OS or leaving unusable space in memory can actually happen?

Pardon me if I am asking a silly question, but I want to know if I can freely test out and learn about using c data types. Thank you!

[MrFariator]

From FFI's semantics docs:

The FFI library has been designed as a low-level library. The goal is to interface with C code and C data types with a minimum of overhead. This means you can do anything you can do from C: access all memory, overwrite anything in memory, call machine code at any memory address and so on.

The FFI library provides no memory safety, unlike regular Lua code. It will happily allow you to dereference a NULL pointer, to access arrays out of bounds or to misdeclare C functions. If you make a mistake, your application might crash, just like equivalent C code would.

This behavior is inevitable, since the goal is to provide full interoperability with C code. Adding extra safety measures, like bounds checks, would be futile. There's no way to detect misdeclarations of C functions, since shared libraries only provide symbol names, but no type information. Likewise, there's no way to infer the valid range of indexes for a returned pointer.

Again: the FFI library is a low-level library. This implies it needs to be used with care, but it's flexibility and performance often outweigh this concern. If you're a C or C++ developer, it'll be easy to apply your existing knowledge. OTOH, writing code for the FFI library is not for the faint of heart and probably shouldn't be the first exercise for someone with little experience in Lua, C or C++.

As a corollary of the above, the FFI library is not safe for use by untrusted Lua code. If you're sandboxing untrusted Lua code, you definitely don't want to give this code access to the FFI library or to any cdata object (except 64 bit integers or complex numbers). Any properly engineered Lua sandbox needs to provide safety wrappers for many of the standard Lua library functions — similar wrappers need to be written for high-level operations on FFI data types, too.

Generally your application will simply crash, usually due to an illegal operation like dereferencing a NULL pointer, or illegal memory access. In these cases, usually your OS will just terminate the process, if not luajit itself. As such, the safety generally depends on what you're doing with the FFI code. Some typical C interfacing (granted you can trust the code you're interfacing with) or using C data types shouldn't pose a significant risk, though.

[qwdqwqwffqw]

Yes, I am talking about if there is potential risk in simple memory writing, not in untrustable code/functions(where there is always a different type of risk). To give explicit example :

Code: Select all

ffi = require "ffi"
x = love.data.newByteData(10) -- 10-byte object
a = ffi.cast("uint8_t*", x:getFFIPointer())
a[5] = 100 -- 1) this is just fine.
a[20] = 55 -- 2) assigning value in position of memory that shouldn't be allowed(this doesn't crash program)..
print(a[20]) -- 3) actually we can see the 'illegal' memory assignment actually happened.

in 2) we are clearly 'touching' the memory that shouldn't be controlled without getting any error. So can I be sure if program don't crush that memory position was not being used(both in LOVE and other program)?

[pgimeno]

You don't have any such guarantee. What doesn't crash in one run may crash in a different run, depending on where the buffer is allocated. Just try to avoid buffer overruns like that. FFI is powerful, but requires care.

[qwdqwqwffqw]

Thank you for the answer.

To elucidate my concern, there are four cases :
1) Writing on wrong memory location, which is NOT used by any other process >> but no crashing.
2) Writing on wrong memory location, which is NOT used by any other process >> LOVE crashes.
3) Writing on wrong memory location, which IS used by any other process >> but no crashing.
4) Writing on wrong memory location, which IS used by any other process >> LOVE crashes (but not affecting other programs/OS)

I am OK with case 1/2/4, but I was wondering if case 3 can actually happen - where wrong code can mess up other process, instead of crashing/being terminated.

[slime]

You generally can't read/write memory owned by other processes in modern operating systems (each process has a separate virtual memory 'view', so to speak).

Aside from that, when you write to memory you didn't allocate there's no guarantee about what will happen to your program. It might crash, it might corrupt some other part of the program without crashing (which is usually much worse than crashing because it can cause very subtle but very bad bugs), etc.

That memory only lasts as long as your process is alive though, nothing permanent will happen unless you do something that writes to a file.

[qwdqwqwffqw]

That clears up all my questions. Appreciate your help!!