Skip to content

Lua global "load" still accepts bytecode #182

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hce opened this issue Jul 27, 2020 · 5 comments
Closed

Lua global "load" still accepts bytecode #182

hce opened this issue Jul 27, 2020 · 5 comments
Milestone

Comments

@hce
Copy link

hce commented Jul 27, 2020

As I understand it, LuaContext's load function only accepts source code to ensure rust's safety semantics cannot be violated by a potentially unpredictable/(faulty behaving when presented with specially crafted input) C function.

  • Looks like from Lua itself, the global "load" function still accepts bytecode.

  • For a project of mine, I compile Lua scripts to bytecode, embed them in the project, and then load them back. Circumventing that limitation by tapping into globals() and retrieving the load function from there.

-> I think the ability to load bytecode should be removed from Lua globals, and maybe string.dump as well.
-> But, to compensate for that loss, I think both functions should be exposed to the rust API as unsafe {} calls?

Do you agree? If yes, I could submit a pull request.

@jugglerchris
Copy link
Collaborator

Hi,

I think we might accept that the Lua load function will accept bytecode (I'm going via @kyren 's comment
#172 (comment) point 5, talking about not trying to patch over every unsafe thing Lua can do), though the Lua constructor should be unsafe.

But I agree that a (probably still unsafe) function to load bytecode from the Rust API seems reasonable.

string.dump seems safe, though, and is fairly easy to call from Rust.

@jugglerchris jugglerchris added this to the Version 1.0 milestone Jul 11, 2021
@jugglerchris
Copy link
Collaborator

This has been fixed as part of #236.

  • The load etc. functions by default are wrapped to only load Lua source
  • unsafe Chunk::into_function_allow_binary() allows loading compiled Lua functions.

@IoIxD
Copy link

IoIxD commented Mar 23, 2023

The load etc. functions by default are wrapped to only load Lua source

The docs suggest otherwise, though. In fact, that part of the docs seems outdated in general.

How would one NOW go about turning Lua bytecode into a function?

@IoIxD
Copy link

IoIxD commented Mar 23, 2023

My mistake, there was a different issue with my code; the bytecode wasn't properly getting loaded in the proc macro I made that embeds said Lua code. As it would turn out, the docs are correct on that front.

However the docs also suggest using eval without any generic parameters, which would suggest they are outdated.

@jugglerchris
Copy link
Collaborator

Hi. I think the examples are correct (at least the first couple I looked at), and would fail the doctests if they weren't.
Instead of passing the type parameter, it's being inferred from the type of the variable the result is being assigned to:

let add2: Function = lua_context.load(r#"
    function(a)
        return a + 2
    end
"#).eval()?;

Or I might not be looking at the same one as you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants