this post was submitted on 29 Jul 2023
31 points (100.0% liked)

Rust

6005 readers
5 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] BB_C@lemm.ee 3 points 1 year ago (9 children)

I'm afraid this question doesn't make a lot of sense. You seem to be confused about the purpose of the painter tool, or how macros work, probably both.

Neither is painter a sandbox tool, nor do macros have the ability to "run code", arbitrary or otherwise, anywhere.

painter is just a call graph analysis tool for the crates.io ecosystem. It does the analysis based on generated LLVM IR code (which is not "runnable" as is) from all versions of all crates.

It's security application is to reliably find what crate releases are vulnerable if a vulnerability is found in releases of crate Foo.

Note that we already have cargo-audit and advisory-db. painter's goal is to confirm via call graph analysis that "Yes, your crate is vulnerable. This part of your crate calls this vulnerable part of crate Foo".

No crate code is actually run by or in painter, except the code written to run the tool itself, of course ;)

As for Rust macros, they get expanded in the parsing stage after lexing. You can see what's literally expanded with cargo expand. Macros are long gone by the time you get to code generation.

Incidentally, painter has this current limitation listed in the README:

  • LTO and optimizers are disabled to prevent inlining, but many cases exist in which the invocation is lost at a bytecode level. Source analysis can improve this. Examples of cases where an invoke is likely lost:
    • Dynamic function calls (pointers, vtables, etc.)
    • Inlining

That's real source/expanded code lost by the time we got to the generated IR code stage. For macros to "run arbitrary code" at that stage would be quite something ;)

[–] kornel@lemmyrs.org 3 points 1 year ago (8 children)

To generate the LLVM code correctly you need to run build.rs if there is any, and run proc macros which are natively compiled compiler plugins, currently running without any sandbox.

The final code isn’t run, but the build process of Cargo crates can involve running of arbitrary code.

The compilation process can be sandboxed as a whole, but if it runs arbitrary code, a malicious crate could take over the build process and falsify the LLVM output.

[–] RunAwayFrog@sh.itjust.works 1 points 1 year ago (4 children)

Hello kornel.

Assuming you have the data, do you mind sharing how many crates in their latest version use compiler plugins?

[–] kornel@lemmyrs.org 1 points 1 year ago (1 children)

At least 69K, which is over half of all crates — https://lib.rs/quote is used almost exclusively for output of proc macros.

[–] RunAwayFrog@sh.itjust.works 1 points 1 year ago (1 children)

Oh, we are calling proc-macro crates "compiler plugins"! I didn't realize.

[–] kornel@lemmyrs.org 1 points 1 year ago* (last edited 1 year ago) (1 children)

They are dlopened by the rustc process. You can totally mess with it: https://nitter.net/m_ou_se/status/1368632701448818691

[–] RunAwayFrog@sh.itjust.works 2 points 1 year ago

I'm aware.

I just find calling the average proc-macro crate a "compiler plugin" a little bit baffling/confusing.

Isn't the term "compiler plugin" reserved for crates/tools that depend on rustc, like clippy?

load more comments (2 replies)
load more comments (5 replies)
load more comments (5 replies)