[PATCH] D58102: Support X86 Control-flow Enforcement Technology (CET) in LLD

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

In D58102#1415608 <https://reviews.llvm.org/D58102#1415608>, @ruiu wrote:

> I'm not still convinced that having the mechanism to automatically enable/disable CET depending on how input object files are compiled is a good idea. It seems really bad idea to me. I'd think the right way to roll out CET is (1) compile source files with CET enabled, (2) enforce CET at the linker, and (3) permanently keep the linker option so that CET is not accidentally turned off. Step 3 is in practice mandatory for programs that you want to use CET, or otherwise you are exposed to risk of accidentally disabling it. And if you have to enforce CET at the linker level for programs you are serious about their security, there's no point of "automatically" enabling it. Rather, I'd think that a security mechanism that is "likely" automatically turned on is more harmful than helpful; that gives a false impression that a user's program is protected with CET even if it's not. I seems to me that that's a dangerous situation and would cause security issues that can be prevented now. Enabling and disabling security mechanism should be an intentional choice.


Just to check I understand, I think your concern is that as the feature is enabled automatically when it is safe to do so, but is silently disabled if at least one object is not marked correctly, so users can't be sure that their binaries are protected without checking the output .note.gnu.property section?

I've tried to sum up the possibilities in the table below. With Auto behaviour as proposed in this patch and I believe is implemented in ld.bfd. The Manual behaviour is my extrapolation of an alternative behaviour, I think we'd have to do something when all the inputs had the CET property and the user hadn't set the linker command line flag otherwise we'd have an equivalent user expectation problem that the feature would be enabled.

| Linker CLI switch | All input objects have property | Auto behaviour                                                         | Manual behaviour                                                                     |
| on                | yes                             | Enable feature (PLT and mark output)                                   | same as Auto                                                                         |
| off               | yes                             | Enable feature (PLT and mark output)                                   | Warn "All inputs have CET but you have not enabled it, did you mean to switch it on? |
| on                | no                              | Do not enable feature, Warn or error, diagnose objects missing feature | same as Auto                                                                         |
| off               | no                              | Do nothing                                                             | same as Auto                                                                         |
|

At this stage I couldn't definitively say that Auto is better than Manual or vice-versa. However if GNU ld has already implemented it one way and we have a community of people expecting it to work that way it seems like it is worth following suite unless there is a really good reason not to.

I agree with you that people should always use the command-line option to tell the linker that the feature is desired/required. If there is a common command line between ld, bfd and to a lesser extend gold, then the linker driver should set it if the compiler flag has been used.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58102/new/

https://reviews.llvm.org/D58102