3

CFI: Handle dyn with no principal by maurer · Pull Request #123003 · rust-lang/r...

 1 month ago
source link: https://github.com/rust-lang/rust/pull/123003
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Handle dyn with no principal by maurer · Pull Request #123003 · rust-lang/rust · GitHub

Contributor

In user-facing Rust, dyn always has at least one predicate following it. Unfortunately, because we filter out marker traits from receivers at callsites and dyn Sync is, for example, legal, this results in us having dyn types with no predicates on occasion in our alias set encoding. This patch handles cases where there are no predicates in a dyn type which are relevant to its alias set.

Fixes #122998

r? workingjubilee

rustbot

added PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

labels

Mar 24, 2024

Collaborator

Some changes occurred in compiler/rustc_symbol_mangling/src/typeid

cc @rust-lang/project-exploit-mitigations, @rcvalle

Some changes occurred in tests/ui/sanitizer

cc @rust-lang/project-exploit-mitigations, @rcvalle
@@ -290,7 +290,7 @@ impl<'tcx> ty::List<ty::PolyExistentialPredicate<'tcx>> {

/// have a "trivial" vtable consisting of just the size, alignment,

/// and destructor.

pub fn principal(&self) -> Option<ty::Binder<'tcx, ExistentialTraitRef<'tcx>>> {

self[0]

self.get(0)?

I don't like changing this invariant in rustc_middle just because CFI makes bad types 😞

workingjubilee reacted with thumbs up emoji

No other place in the compiler expects or constructs dyn types with no predicates.

Contributor

Author

Since later on in the type encoding process, this type will be examined under normalization, I can't just guard against calling principal in the calling code. Given your comment, that probably means I need to avoid constructing 0-predicate dyn

Do you have suggestions for predicates or representations that would make sense here? The case in question is that I have a dyn Send and dyn Sync - they share a vtable. This vtable has one method, drop_in_place. For purposes of checking the alias set, do you have opinions on what it should be encoded as? The only thing I will know about this object at the method site is that it is a dyn with no principal.

Three possible encodings that come to mind:

  • dyn Drop - I don't like this because these types may not implement Drop, and methods which require fn drop shouldn't go here, but it is descriptive.
  • dyn Sized - I'm considering this specifically because you can't normally have a dyn Sized object, and so it can't accidentally match anything else.
  • Contract the entire receiver to *mut () - this technically discards the alias set restriction that someone made a dyn out of this type at some point in the program, but should otherwise be fine. Note - switching from *dyn to *` is safe in this particular situation because this is only being used to encode vtable calls, which are already using thin-dyn pointers.

I'm currently adjusting my code to use the *mut () approach, but figured I'd lay out my thoughts and see if you have a different opinion.

You could perhaps use dyn Destruct, which every type currently implements (and approximately matches the fact that all we know is that it has a drop_in_place)?

*mut () also works I guess.


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK