Why is the FFI enabled?

[pekka]

So, I installed Love 0.9.1 to keep up to date on what you guys are doing. Great thing that you added LuaJIT + all the other stuff.

I wonder about enabling the LuaJIT FFI though. Why is that? A search on the forum didnt' given a single match for the word 'ffi', so I figured I ask. Did you decide to enable it on purpose, and if so, what is this purpose?

The big issue is that the FFI allows you to call external C functions from the standard C library, Windows API (on a Windows computer) and any dynamically linked library that may be laying around. This strikes me as being against the philosophy of Love that I imagine involves keeping the game in a sandbox and allowing it to access the computer and the filesystem only via the APIs provided by Love. It also makes writing malicious Love packages really uncomfortably easy, which means running untrusted Love games is even more unwise than previously.

On the plus side, I think you can access the full OpenGL api and write proper 3d programs now. Didn't try it yet, but since the FFI is there, isn't that now not only allowed but encouraged by Love? Forget the graphics functions and just roll your own display logic?

Here is an example program that calls the C function exit to quit the program. I expect it to work everywhere, but confirmed that it does only on a Linux box.

Code: Select all

local ffi = require 'ffi'

ffi.cdef 'void exit(int)'

function love.draw()
	love.graphics.print("Press a key to quit", 50, 50)
end


function love.keypressed()
	ffi.C.exit(666)
end

The FFI is documented in the link below.

http://luajit.org/ext_ffi.html

Note that I'm not saying I want this to go away completely. I'm just asking why is it enabled by default!

[Karai17]

FFI was enabled to give developers more options.

[bartbes]

Let's preface this by saying ffi was already on in 0.9.0 and before that in any luajit build of love (but there were no official ones). Also, ffi is enabled by default when using luajit.

Now, as for your security concerns: Love never was safe. And it wasn't (and isn't) meant to be, love.filesystem is there because it's a lot easier too, and, of course, portable. If you want something secure then you could look at Robin's SELOVE fork (Security Enhanced Love), but even that is not guaranteed to be completely safe. (As a side note, in the past he actually did a small competition to see who could find holes in SELOVE, and he fixed those too.)

Now, before you think you can make love completely safe, let slime just crash your gpu with a shader. Or we can spawn threads and allocate memory and open files. There's so many means of making a computer crash, malfunction, sluggish or otherwise impaired, the only solution to having a "safe" system is this: don't run any software.

Long story short, you should only run software you trust, whether it's a love game or not.

[slime]

As an aside, you could use standard Lua's os.exit function instead of going through LuaJIT's FFI to do that.

LÖVE doesn't disable any Lua or LuaJIT functionality by default. However, LÖVE itself doesn't rely on the FFI either right now, so unless a specific game requires it, your copy of LÖVE doesn't need to have it.

[pekka]

Let me spell out some basics for people.

Safety isn't a binary concept that you either have or do not have. There are degrees of safety. Hanging a GPU with a misbehaving shader is a whole lot different from installing a rootkit and running amok in your filesystem. The thing is that it's a whole lot easier to recover from one of these.

Also, I don't really have safety concerns since I don't run random Love thingies in the first place. I was asking if you have any concerns yourself as developers, or if there is some sort of a design philosophy to Love. As in, if you prefer people to use or not to use FFI in their games. (These might be useful things to tell your users someday. IF you ever make up your mind.)

I wasn't also looking for a way to exit my programs via FFI. I just picked exit as a relatively harmless C function to call with an effect even the less astute people here would notice on running the program. Oh well. You sometimes have to spell everything out or be misunderstood.

You could have avoided these derails and answered my question. It's something you could have started with "We decided to enable FFI because..."

Anyway, I'll try to remember to be clearer in my questions if I have any more in the future. Now, I'm not blaming just you for misunderstanding me. There's a little thing you can try to do yourself, though, in the future. If you are asked something, don't try to explain what the other guy is thinking or in your opinion should think, but just instead explain what you are thinking. It's usually what I'm after when I ask a question.

Just to be clear, I don't have any more questions on this issue. I'm quite satisfied with thinking that you don't know what you are going to do with the FFI and that's quite all right. It's always possible to decide later.

[bartbes]

Thank you for your wonderful reply, I'll let you know you can expect all the help in the world from me in the future, as I will not even try to understand what you're saying, I'd just get it wrong anyway.

[Ensayia]

The LOVE developers didn't specifically enable the FFI.

They LOVE developers did compile with LuaJIT which provides significant performance improvements on mathematical operations among other things. By compiling with LuaJIT, the FFI is exposed to LOVE. It does not appear to be optional. (This may not be entirely true I guess...)

LOVE never has been nor ever will be a 'secure' program. There are hundreds of ways to infect and abuse computers with any number of programs and LOVE is no exception.

[slime]

Indeed, LÖVE moved from Lua 5.1 to LuaJIT primarily because LuaJIT's JIT compiler and hand-optimized interpreter can be orders of magnitude faster than regular Lua.
The FFI is a nice bonus when used right, but we didn't explicitly enable it, LuaJIT comes with the FFI unless you explicitly disable it when compiling LuaJIT.

The performance of many of LÖVE's functions could be improved (sometimes significantly) if the functions used FFI-based C bindings instead of regular Lua-C API bindings, but some platforms (e.g. iOS) disallow the use of JIT compilers. In a situation like that the FFI will be several times slower than the traditional C API for bindings.

Since I don't really want to maintain two separate sets of bindings for each LÖVE function and LÖVE wouldn't really be able to purely use LuaJIT's FFI, LÖVE doesn't use the FFI itself right now.

I was asking if you have any concerns yourself as developers, or if there is some sort of a design philosophy to Love. As in, if you
prefer people to use or not to use FFI in their games.

As has been mentioned already, straight LÖVE is not sandboxed. LuaJIT's FFI is useful sometimes, both as a way to expose functionality LÖVE doesn't provide on its own and as a way to improve performance in some situations.
However it is also unsafe, and I don't really mean security-wise. It does not hold your hand if you make a mistake (a common one being off-by-one problems when dealing with an FFI-created C array, which is 0-based, compared to Lua's 1-based indexing.)

http://luajit.org/ext_ffi_semantics.html#policy

I only recommend using it in a project you're going to share if you're familiar with C or C-like languages, and have a good reason to use it. It can easily be the cause of bugs in your program.


I almost didn't reply because I was put off by your condescending and hostile attitude. I don't think it does anyone any favours.