RFC: Memory exploit mitigation

[kmcallister]

Rendered view.

[zwarich]

I'm not sure I like the magic integer levels of protection.

[kmcallister]

What about it specifically?

[zwarich]

I would prefer descriptive names rather than integers.

[pczarn]

Integer levels symbolize the acceptable cost that varies between platforms for certain measures. I would prefer approximate cost passed as a percentage of slowdown.

• --harden-cost 5 rather than --harden-level 1
• --harden-cost 20 for --harden-level 2
• --harden-cost 90 for --harden-level 3

[kmcallister]

@zwarich: Okay, something like none, mild, full, extreme? Integer levels are already established practice for optimization, but maybe we should improve the status quo and use descriptive names for optimization as well.

@pczarn: I think users will get annoyed at how rough these approximations are. The actual cost depends a lot on the program you're compiling.

[bharrisau]

None should be none. If I want to disable any changes to the source from these changes I should be able to.

[kmcallister]

I don't really think of it as "changes to the source", since the translation from Rust source to machine code is always very complex. I was more thinking, if there are natural things to do in codegen that would incidentally make exploits harder, we don't need to go out of our way to disable those things at -H0. But I'm not sure what would go in that category, and I do see the appeal of a setting for "make compilation as simple as possible", even if it's still not very simple :)

[bharrisau]

The proposed 0-3 looks similar enough to the well known GCC optimisation levels. None, quick+dont_increase_size, slow+dont_increase_size, maximum.

The biggest difference is between the -O2 and -H2 modes, -H2 is closer to -O3 than -O2. Given -O2 is the 'common' optimisation level perhaps it would be better to have something like the following (sorry for the bikeshedding).

• 0 - No hardening.
• 1 - Incidental things that make exploits harder, if they have no undesirable impact.
• 2 - A level of hardening suitable for most software.
• 3 - A level of hardening suitable for production software which heavily prioritizes security.
• 4 - Maximum hardening.

I know this adds another level, but it matches much closer to the -O system. I'm not sure -H4 has much use except for experimenting/testing.

[pczarn]

You convinced me that levels of hardening are most suitable.

Remember that -O4 doesn't exist, it's an alias for -O3. LTO is enabled separately. Let's look for similarities between optimization and protection. Is RELRO sort of a link time hardening?

[thestinger]

RELRO makes the GOT read-only after the linker sets up the function pointers, so full RELRO requires using immediate binding. You can use both PIE (for a randomized base) and full RELRO today with -C link-args="-Wl,-pie,-z,relro,-z,now".

[thestinger]

AFAIK PIE is the only reason for using LLVM's pic relocation model for an executable, so it can simply be enabled if the relocation model is pic. That's already the default model, so it will be enabled by default everywhere. It may make sense to use dynamic-no-pic by default on architectures like i686 where position independent code is expensive, but that's a separate issue and -C relocation-model=dynamic-no-pic is already possible. See rust-lang/rust#16340.

[brson]

Discussed in https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-08-26.md

@kmcallister the feeling right now is that we're kind of uneasy about 'hardening' as an independent concept in Rust, and would basically like to let the requirements bake more. In the meantime, the individual codegen features involved would be considered on their own merits as codegen compiler flags, and don't need RFC's. In other words, let's go ahead and get started on adding the required codegen functionality to the compiler, but not commit to any unifying framework.

In the future, we should revisit, and possibly take a more holistic look at how codegen options are managed generally (not just those that relate to hardening).

Closing.