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.

[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