Interop Safety: Improving cross-language analysis by augmenting LLVM IR with Rust type information

[obraunsdorf]

Duration: 2h

Scheduling: I'm only there until Thursday. Some time in the morning would be great.

Description:

• 20min Introductory Talk: Introducing the SafeFFI project (https://www.plai.ifi.lmu.de/publications/usenixsecurity26-safeffi.pdf) and the BorrowSanitizer project (https://borrowsanitizer.com/) as two motivating examples for augmenting LLVM IR with additional type information from MIR during compilation. Showing how this can aid tooling for safe interop.

• 60min Open Discussion:

  • Discussing which LLVM-based analysis tools could benefit from additional type info from Rust.
  • Discussing a unified design for rustc's codegen module to augment LLVM IR with additional type information from MIR

• Who should attend: @1c3t3a @dingxiangfei2009, people from the codegen-team (I only expect a small group)

• Hardware: Projector or TV.

[ZuseZ4]

@obraunsdorf On the std::autodiff side, we're already lowering MIR type info to LLVM-IR: https://rustc-dev-guide.rust-lang.org/autodiff/type-trees.html
Our motivating example is on the bottom left: https://c.wsmoses.com/posters/Enzyme-llvmdev.pdf
Enzyme is an LLVM plugin, which already impelemnts a type analysis (including things like offset argumentations, which I've also seen in your paper)

I was always a bit uncomfortable with generating more types, given that LLVM generally moved away from them towards opaque ptrs, so we're not generating all that much info, but we have the infrastructure in place to extend it easily.
I'd be very happy if that could be made a bit less weird / more usefull by sharing it.

Generally, it looks more like you're wondering if a pointer is safe/unsafe/.., whereas we care about the type (ptr-to-ptr, ptr2int, ptr2float, ptr2double, etc). But maybe there's still some potentail for shared infra?
I'd also like to attend the MIR-Move optimization talk, but I'd be happy to join otherwise if you think it's similar enough.

[obraunsdorf]

@ZuseZ4
Ah, that's interesting to hear. Thanks for bringing Enzyme up!

For me, it is about getting an overview of different use cases for "augmenting LLVM-IR with MIR info". And yes, see if there are common flows and hurdles and if it makes sense to build shared infrastructure, or if the use cases are so different that having a generalized infrastructure reduces flexibility.
And I'd like to learn from others how they implemented this and how things should be done in the rust compiler.

So I think it would be nice having you as part of the discussion. It would be interesting to hear about how you implemented augmenting TypeTrees and what feels "weird" about your solution (I looked at rust-lang/rust#144197 to get a grasp but would be nice getting an overview from you).
But if you want to attend another session, we can probably find time to speak on Tuesday or Wednesday I'll try to bring your view into this session. :)

[ZuseZ4]

It looks like your session is 2 hrs, right? I can definitely make the second half, so if you could give me a short recap at the beginning, or we meet at any earlier slot then we should still have a full hour to discuss. I'll also try to add a little bit more of typetree info to the dev-guide, during my flight tomorrow.

[icmccorm]

I can't make it to RustWeek this year :( but here are my current thoughts, and some context on BorrowSanitizer.

• Retag calls are making their way upstream, starting with #156208 and #156210. These bring Miri's retagging operations down to the LLVM IR level. You can view the full design here.

• I'd love for there to be some notion of "exposure to unsafety" available at the LLVM level. ERASan did this with !unsafe and !rawptr annotations, but I'm not sure if that would work as a general-purpose solution. If you are instrumenting a multilanguage LLVM module, then you need to know which components originate from Rust to be able to figure out if a pointer without any annotation is free from UB.

• For optimizing BorrowSanitizer, we would benefit from having something similar to what SafeFFI has for marking casts between references and raw pointers. This seems much more compatible with a multilanguage application. We'd need annotations for transmute, too, which would need to account for reference-to-reference casts as a source of UB.

[obraunsdorf]

I can't make it to RustWeek this year :( but here are my current thoughts, and some context on BorrowSanitizer.

• Retag calls are making their way upstream, starting with #156208 and #156210. These bring Miri's retagging operations down to the LLVM IR level. You can view the full design here.

• I'd love for there to be some notion of "exposure to unsafety" available at the LLVM level. ERASan did this with !unsafe and !rawptr annotations, but I'm not sure if that would work as a general-purpose solution. If you are instrumenting a multilanguage LLVM module, then you need to know which components originate from Rust to be able to figure out if a pointer without any annotation is free from UB.

• For optimizing BorrowSanitizer, we would benefit from having something similar to what SafeFFI has for marking casts between references and raw pointers. This seems much more compatible with a multilanguage application. We'd need annotations for transmute, too, which would need to account for reference-to-reference casts as a source of UB.

Great, thank you! I'll bring your points up in the discussion :)

[obraunsdorf]

It looks like your session is 2 hrs, right? I can definitely make the second half, so if you could give me a short recap at the beginning, or we meet at any earlier slot then we should still have a full hour to discuss. I'll also try to add a little bit more of typetree info to the dev-guide, during my flight tomorrow.

Yes, that's right. Well, I just requested 2 hours so we have time to discuss depending on how many people join and how fast we can come to conclusions. But I'll definitely be there until you join and then I'll give you a quick recap. :)

[ZuseZ4]

Nikita and I will run a few minutes late, mir move meeting is just ending

[obraunsdorf]

Hi everyone :)
Thank you again for participating in this session. It really was a pleasure sharing and discussing ideas with you!

Unfortunately, I did a bad job at taking notes on that day :D
Below are a few points that were important to me in the discussion.
Just tagging everyone who I remember was there to keep you posted. And maybe you have some more notes you want to share :)
@hwright @cramertj @saethlin @gnzlbg @ZuseZ4 @nikic @1c3t3a @dingxiangfei2009
(@tmandry, @icmccorm)

• Overall: LLVM annotations with MIR type info seems helpful for a couple of different use cases. There is general support for this idea and bringing this upstream.

• Using intrinsic calls as marker/annotation should work best, and should preserve annotation during optimization passes (as opposed to using LLVM-MetaData nodes for annotation)

  • might block some optimizations

• Better implement the annotations as MIR transformation passes, such that they are self-contained and as independent of codegen/backend as possible.

  • Helps with upstreaming, and reviewing.
  • Also good not to merge MIR and LLVM-IR semantics but to base analysis/instrumentation them purely on MIR semantics
    • might loose some optimization potential (less precise annotation at LLVM level) at first. But this can be a good starting point to get everything upstream.

• Which LLVM-based tools did we discuss that can benefit from annotations?

  • SafeFFI
  • BorrowSanitizer
  • Enzyme
  • Maybe SeaBMC model checker?

• Which kinds of information are annotated in existing tools? Where do they originate from?

  • Retag statements (MIR): BorrowSanitizer
  • Safe/Unsafe types of ptr variables/arguments (MIR): SafeFFI, BorrowSanitizer
  • Safe/Unsafe basisblock / function (MIR?):
  • Type Layout for parameters and memcpy instructions (AST): Enzyme
  • Operations that take ownership vs borrowing (MIR?): SeaBMC?

From what I learned I'm thinking we could support common use cases by creating multiple MIR Passes, one for each kind of information we want to transport to LLVM-IR. Having each one behind a compiler flag like -Z emit-<infoXYZ> such that tool developers can reuse and plug together as needed.