Mitigation enforcement

[arielb1]

Zulip: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Mitigation.20enforcement.20.28.60-C.20allow-partial-mitigations.60.29/with/539293124

Rendered

[clarfonthey]

FYI: Your rendered link doesn't work because you updated the filename in the URL to account for the PR number, but didn't actually update the filename in the code itself.

[arielb1]

FYI: Your rendered link doesn't work because you updated the filename in the URL to account for the PR number, but didn't actually update the filename in the code itself.

Fixed

[Noratrieb]

Can you use the words "dependency" instead of "child" here and above? Child is not a word we generally use for crate relationships which makes it a bit confusing

[Noratrieb]

You always talk about stack-protector here, since that's your primary motivation of course, but I think it would be good to more explicitly list out all kinds of mitigations that Rust has it that people would like Rust to have in the future, to ensure that this makes sense for all of them (for example, the ones from https://doc.rust-lang.org/nightly/rustc/exploit-mitigations.html#exploit-mitigations-1).

I would especially be interested in whether there are existing stable mitigations that would like to make use of this, especially if it has a flag to toggle it.

[rcvalle]

Some exploit mitigations that would benefit from it (e.g., CFI, and including most in the https://doc.rust-lang.org/nightly/rustc/exploit-mitigations.html#exploit-mitigations-1) precedes the Target Modifiers feature (which was intended to also solve this), but I don't think there are any stable exploit mitigations except maybe -C control-flow-guard.

[ojeda]

Some projects may already have tooling to check certain things are as expected, e.g. objtool in the Linux kernel -- perhaps worth mentioning in "Motivation" or "External tools" sections. Of course, having a higher level layer checking things look OK is good, and likely could cover different aspects and would work for more projects.

[arielb1]

Some projects may already have tooling to check certain things are as expected, e.g. objtool in the Linux kernel -- perhaps worth mentioning in "Motivation" or "External tools" sections

I mentioned hardening-check. If you have experience with objtool, you can add that as well.

I also couldn't find any documentation for objtool used as a hardening check tool, so if you could provide me some I would try to include it.

[ojeda]

The docs are here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/Documentation/objtool.txt

I mentioned objtool because it is lower level, e.g. it inspects the instruction stream and so on, while hardening-check, AFAIK, is more about probing declared information using other tools (mainly, at least, from a quick look -- Cc @kees).

[arielb1]

So it looks like it works on a per-.o file basis rather than on a per-executable/shared-library basis, so it requires controlling the linker, basically.

Is that right?

hardening-check, AFAIK, is more about probing declared information using other tools

hardening-check is a lot less sophisticated, but it does perform some checks on the instruction stream - e.g. looking for checks to stack_chk_fail. It also works on executables rather than object files.

I do think that the big difference is "tool that works on .o files vs. tool that works on executables", since if the tool needs .o files you have to use it as a part of the compilation process.

[ojeda]

it does perform some checks on the instruction stream - e.g. looking for checks to stack_chk_fail

I don't think the stack_chk_fail check counts as "checks on the instruction stream". The one that comes close to that is the stack clash one, which is essentially checking regexes against the disassembly.

since if the tool needs .o files you have to use it as a part of the compilation process.

objtool has checks on linked files too, and more generally one could make a tool that works on final executables (there are very advanced analyzers out there, after all). In any case, projects that care about these bits (i.e. those with custom tools like the kernel) can likely deal with a custom build process that inspects object files. So I don't think that is a big difference -- I would say the big differences are the use case and the level at which the checks are performed.

Anyway, none of the above really matters -- I mentioned objtool because it is the kind of tool that the "Why not an external tool?" section (or the motivation) should probably mention, given it is a good example of a tool that is able to perform certain non-trivial low level checks for a quite complex project (and is open source). Having more layers checks things from different angles is good! :)

Thanks for working on this!

[arielb1]

If there was a "magic" analyzer that would reliably do the sanitizer enforcement, there would be much less need for it as a compiler flag.

As far as I can tell, the existing analyzers either have large holes or require significant project-specific intervention.

That of course does not mean they are not useful, only that they don't automatically solve the problem for everyone.

[ojeda]

Not sure if there is a disagreement here, but just in case: I didn't claim there is a "magic" analyzer out there solving this. Quite the contrary -- I said that even if such a tool existed that covered everything, having an independent check at another layer like this RFC proposes would still be useful. The objtool relevance is not because it solves the issue completely or for every project, but rather because it is an important example of such tooling, especially since the Linux kernel is mentioned.

[burdges]

It's be cool if this was somehow per dependency, like maybe you'd add some disable-mitigation-enforcement = {std} into the binary's Cargo.toml.

[arielb1]

It's be cool if this was somehow per dependency, like maybe you'd add some disable-mitigation-enforcement = {std} into the binary's Cargo.toml.

You probably want something in the style of -C allow-partial-mitigations=stack-protector=std+alloc+core, so you know which mitigations you are allowing.

(Of course, with also a syntax in Cargo, which should come with a separate RFC I think).

[arielb1]

Added that to alternatives

[Noratrieb]

Specifying crate names from the sysroot is very problematic since std has about 10 different dependencies that would need to be specified and that are not stable.

What would we desired for this use case of allowing the sysroot and nothing else would be special syntax to allow it only in the sysroot. A list of crate names would not help.

[arielb1]

What would we desired for this use case of allowing the sysroot and nothing else would be special syntax to allow it only in the sysroot. A list of crate names would not help.

Do you think that special casing core (or @core or something) to apply to the entire sysroot would work?

[teor2345]

It's be cool if this was somehow per dependency, like maybe you'd add some disable-mitigation-enforcement = {std} into the binary's Cargo.toml.

You probably want something in the style of -C allow-partial-mitigations=stack-protector=std+alloc+core, so you know which mitigations you are allowing.

This would still be useful for crates outside std, for example, if a project experiences a mitigation "failure" in a non-security critical crate or feature branch.

[rcvalle]

A summary of the reasoning behind explicitly stating that it is allowed for the Rust compiler to accept a mitigation might be applied partially:

• Allowing the user to inadvertently enable an exploit mitigation partially, or worse having this behavior by default, may lead to considerably reducing the effectiveness of the mitigation without the user knowing about it and thinking the program is otherwise protected or have security guarantees it actually doesn't have.

For solving this, I'm in favor of the simpler -C allow-partial-mitigations[=<mitigation1>,...,<mitigationN>]. It's simple, effective, and cover all cases where we wouldn't want the user to inadvertently enable an exploit mitigation partially (e.g., CFI, Stack Protector, etc.). It also aligns with the Rust philosophy of having the user to explicitly opt for the less safe approach.

For stack smashing protection specifically (which is beyond the scope of this RFC, but relevant to choosing the right approach):

• For stack protector, the most common behavior the user gets for quite some time already is actually globally enabled and enforced, not partially enabled. Most major Linux distributions build their packages with stack protector strong, including the C standard library (which would be the equivalent of always using -Zbuild-std) and have the option implicitly enabled in their toolchains so the behavior the user gets is much closer to always using -Zbuild-std than not. For example, it's enabled by default in Ubuntu for quite some time already (see https://wiki.ubuntu.com/ToolChain/CompilerFlags).

For this, I propose either:

1. That the user has to use -C allow-partial-mitigations=stack-protector to allow it to be applied partially as described above. (Otherwise, the user might inadvertently think they are getting the most common behavior as described above.)
2. Do (1) and enable it with the strong mode/strategy by default both for the Rust standard library and the Rust compiler--this is the default for most major Linux distributions for quite some time already.

For (2), we could perform a comprehensive set of tests for binary size, build time, and run time performance and make a decision based upon the ROI (considering the returns are different from a program written in C or C++ compared to a program written in Rust).

[kees]

The docs are here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/Documentation/objtool.txt

I mentioned objtool because it is lower level, e.g. it inspects the instruction stream and so on, while hardening-check, AFAIK, is more about probing declared information using other tools (mainly, at least, from a quick look -- Cc @kees).

Objtool is mainly designed to validate the expected construction of the (x86) kernel's functions and related metadata (e.g. "can we always unwind the stack correctly?" or "what things are reachable for indirect calls?")

As far as the mitigation enforcement idea as presented, I like the idea of having this be a declared compatibility thing to check. In C it is trivial to mix and match different mitigations and the resulting binary is very hard to analyze after the fact (see hardening-check which is best-effort). Rejecting mismatches up front would be nice! :)

[arielb1]

Do (1) and enable it with the strong mode/strategy by default both for the Rust standard library and the Rust compiler--this is the default for most major Linux distributions for quite some time already.

I do think there is an interesting middle point where we ship a libstd that has stack protector=strong enabled, but don't enable it for default in the toolchain. This means that people can easily enable complete stack protector for their application without -Z build-std, but there is less annoying performance impact.

In any case, it should not be relevant to this RFC.

[davidtwco]

For solving this, I'm in favor of the simpler -C allow-partial-mitigations[=<mitigation1>,...,<mitigationN>]. It's simple, effective, and cover all cases where we wouldn't want the user to inadvertently enable an exploit mitigation partially (e.g., CFI, Stack Protector, etc.). It also aligns with the Rust philosophy of having the user to explicitly opt for the less safe approach.

I also much prefer this approach to having many -noenforce variants of flag values. When a distribution of Rust ships a standard library with a mitigation enabled, then I think there are two ways of doing this that we should encourage:

1. Using -Zbuild-std or an equivalent mechanism. Our draft for build-std rust-project-goals#274 aims eventually to make it so that if a target modifier (or exploit mitigation, I guess) is enabled, then the mismatch with std is detected and std is rebuilt automatically. This seems like a reasonable user experience and addresses this for the Rust project's distribution of Rust.
2. Shipping rustc w/ the default changed to match the flags used with the standard library, so the partial mitigations error doesn't trigger by default when rustc is used without any flags. I think I'd be happy for this to be what a Linux distribution/internal company distribution/etc does - as long as the flags/defaults changed are all otherwise stable.

[teor2345]

The equivalent of -fwrapv in Rust is -C overflow-checks=off. And if you're depending on it rather than one of the other alternatives, you probably want to make sure it's enabled everywhere that isn't using one of those alternatives.

[arielb1]

It's not possible to have the Rust equivalent of -fno-wrapv (undefined behavior on signed integer wrapping).

-C overflow-checks=on is more equivalent to -ftrapv. Do people feel that there is a need to set it to enforcing?

[teor2345]

I understand it doesn't quite fit the model here, but I've written code where we wanted to panic rather than wrapping, because wrapping meant we'd generated an incorrect value.

I've also written code where we relied on the guaranteed wrapping behaviour.

[arielb1]

I'll say this (enforcing for overflow checks) is off scope for the current RFC. There is no reason to do it in the "main" enforcing pulse. Feel free to open another RFC/FCP/whatever.

[Noratrieb]

I agree that it's not really a security mitigation in the classic sense and shouldn't be enforced.

FWIW, relying on wrapping behavior is incorrect, as Rust always considers overflow to be a bug, it just doesn't always check it. Use wrapping if you need wrapping.

[teor2345]

This might need to be clarified. Do you mean a stricter or less strict level in the dependent crate?

It might also be helpful to use the same dependency terms as the previous paragraph (current and dependency). Edit: or change that paragraph to use base and dependent?

[arielb1]

@wesleywiser

Made -C allow-partial-mitigations non-order-dependent the default, since there does not seem like enough desire for the order-dependent variant.

We can probably change our choice over an edition boundary if we want (can we?)