CFI: Skip non-passed arguments #122456

maurer · 2024-03-13T19:39:31Z

Rust will occasionally rely on fn((), X) -> Y being compatible with fn(X) -> Y, since () is a non-passed argument. Relax CFI by choosing not to encode non-passed arguments.

This PR was split off from #121962 as part of fixing the larger vtable compatibility issues.

r? @workingjubilee

workingjubilee · 2024-03-13T19:45:38Z

cc @rcvalle since this affects CFI in general as well.

Can you cite an example of this reliance "in the wild"? For all I know there's already one in the rustc codebase, heh, just curious.

maurer · 2024-03-13T19:49:20Z

The attached test is one such example - it reifies a closure into a function pointer by way of knowing that the closure context is a ZST.

workingjubilee · 2024-03-13T19:52:16Z

Huh, I didn't really think of the closure-to-fn-pointer decay that way, I suppose it makes sense. Can you add a note to the test that the ZST-ness of the captured context is part of what's relevant?

rcvalle · 2024-03-14T06:33:19Z

tests/codegen/sanitizer/cfi-emit-type-metadata-id-itanium-cxx-abi.rs

-// CHECK: ![[TYPE137]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NtNvC{{[[:print:]]+}}_[[ITANIUMED_FILENAME]]3fn13QuxIu3i32Lu5usize32EES2_S2_E"}
-// CHECK: ![[TYPE138]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NcNtNvC{{[[:print:]]+}}_[[ITANIUMED_FILENAME]]3fn15Quuux15{{[{}][{}]}}constructor{{[}][}]}}Iu6regionS_EE"}
-// CHECK: ![[TYPE139]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NcNtNvC{{[[:print:]]+}}_[[ITANIUMED_FILENAME]]3fn15Quuux15{{[{}][{}]}}constructor{{[}][}]}}Iu6regionS_ES0_E"}
-// CHECK: ![[TYPE140]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NcNtNvC{{[[:print:]]+}}_[[ITANIUMED_FILENAME]]3fn15Quuux15{{[{}][{}]}}constructor{{[}][}]}}Iu6regionS_ES0_S0_E"}


Why are you removing all these tests?

These tests are being removed because their ABI coding becomes equivalent. You're passing in a ZST, so they all collapse.

This doesn't seem right. We're losing a lot of granularity there. This seems to be the result of incorrectly removing the ZSTs vs unclosure'ing the Closures.

rcvalle · 2024-03-14T06:34:32Z

tests/ui/sanitizer/cfi-closure-fn-ptr-cast.rs

+//@ run-pass
+
+pub fn main() {
+    let f: &fn() = &((|| ()) as _);


What happens if the closure has parameters?

Then the cast is invalid:

pub fn main() { let x: usize = 3; let f: &fn() -> usize = &((|| x) as _); }

generates

error[E0605]: non-primitive cast: `{closure@src/main.rs:3:32: 3:34}` as `fn() -> usize`

That cast is only legal for closures with no captures.

I was referring to parameters, not captures.

Why would that matter, exactly?

I wanted to know how closures with parameters behave with these changes, but I guess considering all what I've seem and pointed out already this doesn't matter.

rcvalle · 2024-03-14T07:17:25Z

It seems this PR has an incomplete fix for a more general problem of allowing function items, closures, and Fn trait objects to be used interchangeably, which would then become a "complete" solution in your overall solution for KCFI with the addition of shims for it.

As I mentioned in #121962 and to you directly a couple weeks ago, I'm currently working on a fix for this for both CFI and KCFI using type metadata IDs/encoding only (see #116404). which follows the same design of the rest of the CFI implementation by transforming/coalescing types we want to be semantically equivalent into a single entity and passing them for encoding, so the shims aren't necessary in this case even for KCFI.

I'll resolve the merge conflicts and comments in #121962, confirm it fixes this issue, and try to get it merged next week if you don't mind waiting. If that doesn't fix this issue, we can have this merged (pending review).

workingjubilee · 2024-03-14T15:40:45Z

@rcvalle Does C++ actually have a coherent ABI for zero-sized arguments? If so, why is that a "more general solution" to fixing an incoherency in argument encoding? If C++ cannot represent it, why should it be encoded? If we do, we are getting awfully close to, assuming we haven't already passed, abandoning any pretense of actually using the Itanium mangling/C++ logic, and are just making up stuff.

rcvalle · 2024-03-14T16:30:09Z

It's a more general solution for allowing function items, closures, and Fn trait objects to be used interchangeably that doesn't require shims. The ZSTs are gone in #116404 too when unclosure'ing the closures (see the else if is_closure_call in transform_fnabi there).

workingjubilee · 2024-03-14T17:15:51Z

@rcvalle If both erase ZSTs, then why not just land this first?

rcvalle · 2024-03-14T18:02:25Z

Because this actually doesn't solve any problem completely or correctly. The problem isn't erasing ZSTs, the problem is properly unclosure'ing Closures and unwrapping dynamic Fn trait objects and encoding them correctly. This just partially fix the problem by erasing the ZSts from the Closures (instead of properly unclosure'ing them) for later "completing" the fix with shims/trampolines so they can be used interchangeably (also instead of encoding them correctly), which are not necessary.

I just updated #116404 resolving the merge conflicts, fixing and doing a few things pointed out by @compiler-errors, and also added the test from this PR there to demonstrate that it not only fix this case, but more generally the problem I described before (see tests/codegen/sanitizer/cfi-emit-type-metadata-id-itanium-cxx-abi-closures.rs which illustrates it there).

There are still a couple things left to do there that I'll take a look at next week.

maurer · 2024-03-14T18:17:00Z

Because this actually doesn't solve any problem completely or correctly.

I have the complete solution in my full patch stack, but I was just asked to start splitting off smaller pieces which point-fixed some issues. If you want a full solution, look at my primary PR.

The problem isn't erasing ZSTs, the problem is properly unclosure'ing Closures and unwrapping dynamic Fn trait objects and encoding them correctly

This is a separate problem from the ZSTs, and is addressed via the rewrite to ReifyShim in the cfi_shim function in my primary patch.

rcvalle · 2024-03-14T18:20:25Z

It's the exact same problem, but you're solving it by adding shims instead. I mentioned this to you a couple weeks ago when we discussed your solution and I asked you to take a look and rebase your changes on top of it, eliminating these unnecessary shims, which you didn't.

workingjubilee · 2024-03-14T18:26:48Z

@rcvalle Setting aside the shim discussion, I am currently not persuaded that not erasing ZSTs is correct. All of the codegen backends erase ZSTs from fn arguments while emitting code, so why should the typechecking here be different? The languages we're concerned about checking indirect calls from/into don't even have ZSTs as a concept.

rcvalle · 2024-03-14T18:48:01Z

I'm not saying that not erasing ZSTs is correct, I'm saying that just doing it is (and also how it's done manually vs unclosure'ing). Doing it is part of a larger issue that I already explained and repeated here many times: allowing function items, closures, and Fn trait objects to be used interchangeably (see tests/codegen/sanitizer/cfi-emit-type-metadata-id-itanium-cxx-abi-closures.rs which illustrates it).

This PR doesn't solve it at all without adding unnecessary shims later. Just try tests/codegen/sanitizer/cfi-emit-type-metadata-id-itanium-cxx-abi-closures.rs with this PR without the rest of the changes that add the shims and you'll see).

workingjubilee · 2024-03-14T18:58:29Z

@rcvalle As this is an incremental improvement only, split as I requested, I don't see why @maurer would object to reverting these changes if a more complete fix was offered later, and I certainly wouldn't. I would hope that is acceptable to you, also?

I realize that you would prefer shipping a more complete fix, but this entire work has been at least partly about feeling out better solutions and sometimes being surprised by what turns things take.

rcvalle · 2024-03-14T19:08:06Z

What I'm trying to avoid is reverting it a couple of weeks from now along with #116404, and @maurer having to rebase their proposed changes on top of it anyway. What merging this now accomplishes?

workingjubilee · 2024-03-14T19:12:16Z

...I mean, for me, my git-fu is pretty strong, so I'm just kinda assuming "rebase changes on top" isn't actually a big deal.

workingjubilee · 2024-03-14T19:13:40Z

...I mean, for me, my git-fu is pretty strong,

Unless it's a subtree, tbh.

bors · 2024-03-19T05:06:33Z

☔ The latest upstream changes (presumably #122375) made this pull request unmergeable. Please resolve the merge conflicts.

workingjubilee · 2024-03-20T22:32:50Z

I currently do not believe that it is possible for either form of CFI to realistically work without performing some ZST erasure. If it needs to be narrowed in the future from this, I feel that can be done later.

@maurer Can you rebase this? Thanks!

workingjubilee · 2024-03-20T22:36:32Z

@maurer Also, when you do, please add a comment explaining that this ZST erasure is only sensical under PassMode::Ignore, and that this erasure is an implementation detail of how MIR is currently interpreted by rustc that is subject to change in the future.

rcvalle · 2024-03-20T23:29:15Z

If this is merged, it's going to decrease CFI granularity a lot. Basically, all groups of functions distinguished by ZSTs in Rust-compiled code will be gone.

rustbot · 2024-03-21T00:24:26Z

Some changes occurred in compiler/rustc_symbol_mangling/src/typeid

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

Some changes occurred in tests/codegen/sanitizer

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

Some changes occurred in tests/ui/sanitizer

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

workingjubilee · 2024-03-21T19:24:28Z

@bors r+

bors · 2024-03-21T19:24:30Z

📌 Commit 331d856 has been approved by workingjubilee

It is now in the queue for this repository.

CFI: Skip non-passed arguments Rust will occasionally rely on fn((), X) -> Y being compatible with fn(X) -> Y, since () is a non-passed argument. Relax CFI by choosing not to encode non-passed arguments. This PR was split off from rust-lang#121962 as part of fixing the larger vtable compatibility issues. r? `@workingjubilee`

bors · 2024-03-21T20:05:31Z

⌛ Testing commit 331d856 with merge 83dadc0...

bors · 2024-03-21T21:18:14Z

💔 Test failed - checks-actions

maurer · 2024-03-21T21:43:33Z

The failure appears to be that OSX can't build CFI binaries. This patch doesn't adjust codegen, only labels, so if building is failing, it's an existing bug. It's one we should solve, but not a flaw in the patch. I'm going to adjust the test to be //@ only-linux. This is happening because it is the first test we have that actually builds a fully linked binary and executes it.

workingjubilee · 2024-03-21T22:03:45Z

@maurer Please capture the PLT/reloc issue as a FIXME on the test.

Rust will occasionally rely on fn((), X) -> Y being compatible with fn(X) -> Y, since () is a non-passed argument. Relax CFI by choosing not to encode non-passed arguments.

workingjubilee · 2024-03-21T23:20:20Z

@bors r+

bors · 2024-03-21T23:20:22Z

📌 Commit f2f0d25 has been approved by workingjubilee

It is now in the queue for this repository.

bors · 2024-03-22T06:09:44Z

⌛ Testing commit f2f0d25 with merge 7762adc...

bors · 2024-03-22T08:09:33Z

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing 7762adc to master...

rust-timer · 2024-03-22T09:24:24Z

Finished benchmarking commit (7762adc): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-2.3%, -2.3%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 667.777s -> 669.214s (0.22%)
Artifact size: 315.07 MiB -> 314.92 MiB (-0.05%)

rustbot assigned workingjubilee Mar 13, 2024

rustbot added 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 13, 2024

maurer force-pushed the cfi-nonpassed branch from ae37177 to 963dac7 Compare March 13, 2024 19:58

rcvalle reviewed Mar 14, 2024

View reviewed changes

maurer force-pushed the cfi-nonpassed branch from 963dac7 to de4b5c2 Compare March 21, 2024 00:24

rustbot added the PG-exploit-mitigations Project group: Exploit mitigations label Mar 21, 2024

maurer force-pushed the cfi-nonpassed branch from de4b5c2 to e062887 Compare March 21, 2024 00:33

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 21, 2024

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 21, 2024

This comment has been minimized.

Sign in to view

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 21, 2024

maurer force-pushed the cfi-nonpassed branch from 331d856 to 69b17ad Compare March 21, 2024 21:44

maurer mentioned this pull request Mar 21, 2024

OSX CFI produces relocation issues #122848

Open

CFI: Skip non-passed arguments

f2f0d25

Rust will occasionally rely on fn((), X) -> Y being compatible with fn(X) -> Y, since () is a non-passed argument. Relax CFI by choosing not to encode non-passed arguments.

maurer force-pushed the cfi-nonpassed branch from 69b17ad to f2f0d25 Compare March 21, 2024 22:26

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 21, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 22, 2024

bors merged commit 7762adc into rust-lang:master Mar 22, 2024
12 checks passed

rustbot added this to the 1.79.0 milestone Mar 22, 2024

bors mentioned this pull request Mar 22, 2024

CFI: Fix fn items, closures, and Fn trait objects, and more #116404

Closed

rcvalle mentioned this pull request Mar 29, 2024

Revert "CFI: Skip non-passed arguments" #123205

Draft

CFI: Skip non-passed arguments #122456

CFI: Skip non-passed arguments #122456

Conversation

maurer commented Mar 13, 2024

workingjubilee commented Mar 13, 2024

maurer commented Mar 13, 2024

workingjubilee commented Mar 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maurer Mar 14, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rcvalle commented Mar 14, 2024

workingjubilee commented Mar 14, 2024 • edited

rcvalle commented Mar 14, 2024

workingjubilee commented Mar 14, 2024

rcvalle commented Mar 14, 2024

maurer commented Mar 14, 2024

rcvalle commented Mar 14, 2024

workingjubilee commented Mar 14, 2024

rcvalle commented Mar 14, 2024

workingjubilee commented Mar 14, 2024

rcvalle commented Mar 14, 2024

workingjubilee commented Mar 14, 2024

workingjubilee commented Mar 14, 2024

bors commented Mar 19, 2024

workingjubilee commented Mar 20, 2024

workingjubilee commented Mar 20, 2024

rcvalle commented Mar 20, 2024

rustbot commented Mar 21, 2024

workingjubilee commented Mar 21, 2024

bors commented Mar 21, 2024

bors commented Mar 21, 2024

This comment has been minimized.

bors commented Mar 21, 2024

maurer commented Mar 21, 2024

workingjubilee commented Mar 21, 2024 • edited

workingjubilee commented Mar 21, 2024

bors commented Mar 21, 2024

bors commented Mar 22, 2024

bors commented Mar 22, 2024

rust-timer commented Mar 22, 2024

Overall result: no relevant changes - no action needed

maurer Mar 14, 2024 •

edited

workingjubilee commented Mar 14, 2024 •

edited

workingjubilee commented Mar 21, 2024 •

edited