Skip to content

Conversation

@arielb1
Copy link
Contributor

@arielb1 arielb1 commented Nov 26, 2025

This implements -Z allow-partial-mitigations as an unstable option, currently with support for control-flow-guard and stack-protector.

As a difference from the RFC, we have -Z allow-partial-mitigations=!foo rather than -Z deny-partial-mitigations=foo, since I couldn't find an easy way to have an allow/deny pair of flags where the latter flag wins.

To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).

r? @rcvalle

@rustbot
Copy link
Collaborator

rustbot commented Nov 26, 2025

These commits modify compiler targets.
(See the Target Tier Policy.)

@rustbot 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 Nov 26, 2025
@rust-log-analyzer

This comment has been minimized.

metadata_mitigation_less_strict_in_dependency =
your program uses the crate `{$extern_crate}`, that is not protected by `{$mitigation_name}{$mitigation_level}`
.note = Recompile that crate with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Diagnostics must always start with a lowercase letter.

Suggested change
.note = Recompile that crate with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled
.note = recompile that `{$extern_crate}` with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled

metadata_mitigation_less_strict_in_dependency =
your program uses the crate `{$extern_crate}`, that is not protected by `{$mitigation_name}{$mitigation_level}`
.note = Recompile that crate with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled
.help = It is possible to disable `-Z allow-partial-mitigations={$mitigation_name}` via `-Z allow-partial-mitigations=!{$mitigation_name}`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.help = It is possible to disable `-Z allow-partial-mitigations={$mitigation_name}` via `-Z allow-partial-mitigations=!{$mitigation_name}`
.help = it is possible to disable `-Z allow-partial-mitigations={$mitigation_name}` via `-Z allow-partial-mitigations=!{$mitigation_name}`

@Urgau
Copy link
Member

Urgau commented Nov 26, 2025

To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).

I don't think we currently have any command line arguments who is edition depended, that would be a first.

@arielb1
Copy link
Contributor Author

arielb1 commented Nov 26, 2025

I don't think we currently have any command line arguments who is edition depended, that would be a first.

The behavior for -C control-flow-guard is in the RFC. Tho that RFC is not approved yet.

I do think we want to eventually make -C control-flow-guard enforcing, and I think we have to do that across an edition boundary.

Some(s) => {
for sub in s.split(',') {
let (sub, enabled) =
if sub.starts_with('!') { (&sub[1..], false) } else { (sub, true) };
Copy link
Contributor

@teor2345 teor2345 Nov 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using ! for negation on the command-line is non-standard. It might also cause shell command parsing issues, because ! is a history search and insert metacharacter in some common shells.

The standard CLI negation prefix is no-, I suggest we use that instead.

The dev guide says to avoid no- for boolean flags, but I don't think that applies to more complex options:

- Avoid flags with the `no-` prefix. Instead, use the [`parse_bool`] function,
such as `-C embed-bitcode=no`.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I basically put ! as a placeholder. Let's wait with it for a little bit of time until we figure out what to do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest further investigating the possibility of using -Z deny-partial-mitigations=foo instead as described in the RFC.

@arielb1 arielb1 force-pushed the enforce-partial-mitigations branch 2 times, most recently from 2f2a134 to 99913dd Compare November 27, 2025 16:09
@rustbot

This comment has been minimized.

@rcvalle rcvalle added the PG-exploit-mitigations Project group: Exploit mitigations label Dec 5, 2025
could not find native static library `{$libname}`, perhaps an -L flag is missing?
metadata_mitigation_less_strict_in_dependency =
your program uses the crate `{$extern_crate}`, that is not protected by `{$mitigation_name}{$mitigation_level}`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
your program uses the crate `{$extern_crate}`, that is not protected by `{$mitigation_name}{$mitigation_level}`
your program uses the crate `{$extern_crate}`, that is not compiled with `{$mitigation_name}{$mitigation_level}` enabled

metadata_mitigation_less_strict_in_dependency =
your program uses the crate `{$extern_crate}`, that is not protected by `{$mitigation_name}{$mitigation_level}`
.note = recompile `{$extern_crate}` with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.note = recompile `{$extern_crate}` with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled
.note = recompile `{$extern_crate}` with `{$mitigation_name}{$mitigation_level}` enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an executable file that has the mitigation only partially enabled

pub(crate) type TargetModifiers = Vec<TargetModifier>;

/// Enforced Mitigations
pub(crate) type EnforcedMitigations = Vec<EnforcedMitigation>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be easier to have a list of allowed partial mitigations instead (with all mitigations being enforced by default)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be easier to have a list of allowed partial mitigations instead (with all mitigations being enforced by default)?

An "enforced mitigation" is (to me) the name of a mitigation that is enforced according to RFC 3855. Maybe we should call it "EnforcableMitigation"?

In metadata, you need to have the list of enforced mitigations that the dependency crate has enabled.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'm wondering isn't about the naming itself but about a safer default (i.e., all mitigations enforced by default) so we would have an allowlist of mitigations that could be applied partially.

Copy link
Contributor Author

@arielb1 arielb1 Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'm wondering isn't about the naming itself but about a safer default (i.e., all mitigations enforced by default) so we would have an allowlist of mitigations that could be applied partially.

You have to define something as a "mitigation". The way you do it is by putting it in the "enforcable mitigation" list.

There is no programmatic list of "mitigations" other than the enforcable mitigation list

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about something more descriptive like DeniedPartialMitigations? Then you could either have an AllowedPartialMitigations or remove a mitigation from this list when --deny-partial-mitigations is used.

Alternatively, you could have a main Mitigations list defined somewhere in the compiler (or a way to mark an option as a mitigation), and just use an AllowedPartialMitigations list.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EnforcedMitigations is the list of enforced mitigations that are enabled for a crate

if an enforced mitigation is enabled on a crate, and not enabled on a dependency, and is not explicitly "-C allow-partial-mitigation"-d, this causes an error

The "enforced_mitigations! {" list contains the main source of what is considered an "enforced mitigation"

I am not sure it should be tied to flags directly, because you can have stuff like e.g. having both -C stack-protector and -Z stack-protector being the same mitigation

@rustbot rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Dec 5, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 5, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@arielb1
Copy link
Contributor Author

arielb1 commented Dec 10, 2025

Found a way to make -Z deny-partial-mitigations=foo work

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 10, 2025
@arielb1 arielb1 force-pushed the enforce-partial-mitigations branch from 2fabf16 to e561031 Compare December 10, 2025 19:13
@rust-log-analyzer

This comment has been minimized.

@arielb1 arielb1 force-pushed the enforce-partial-mitigations branch from e561031 to 2c3f3b3 Compare December 10, 2025 20:24
@rust-log-analyzer

This comment has been minimized.

Ariel Ben-Yehuda added 3 commits December 10, 2025 21:18
This implements `-Z allow-partial-mitigations` as an unstable option,
currently with support for control-flow-guard and stack-protector.

As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo`
rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy
way to have an allow/deny pair of flags where the latter flag wins.

To allow for stabilization, this is only enabled starting from the next edition. Maybe a
better policy is possible (bikeshed).
@arielb1 arielb1 force-pushed the enforce-partial-mitigations branch from 2c3f3b3 to 33012b6 Compare December 10, 2025 21:48
@rustbot
Copy link
Collaborator

rustbot commented Dec 10, 2025

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@arielb1
Copy link
Contributor Author

arielb1 commented Dec 10, 2025

Addressed rebase problems

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants