Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Need way to properly name retpoline thunks #25
In gcc7 there is support for a number of different functions which are called thunks. These thunks may fire at function entry, return, or be used for indirect calls, among other things. The way that gcc7 names these depends on whether or not it believes that the general system supports what it considers hidden, link-once capabilities. This is summarized in the
Unfortunately, to properly mitigate Spectre v2 in software, we are opting to use retpolines on systems that don't have enhanced IBRS. To do that, one needs to pass the following two options to gcc7:
@richlowe put together a patch for this which basically forces us to name indirect extern thunk types such as those used by retpolines regardless of the USE_HIDDEN_LINKONCE capabilities. The way that gcc7 works here is that there are two different types of ways that the various thunks are compiled:
When using the retpoline configuration described above, the only thunks that are present are the ones emitted via 1. However, because the compiler comes back for others in case two, that is why cfun may or may not be valid in the patch. Further, because of these different types and uses, it seems reasonable that we can override the naming issue when dealing with indirect extern thunks, because they need to refer to a single external name and the implementation will never be part of the compilation unit itself, hence the fact that we force the external name makes sense.
To test this, I've put together a couple different things. First, I built illumos and did a wsdiff between the version with these changes and without it, changing nothing else in illumos. The wsdiff only had noise based on changes in CTF. Next, I did a bunch of testing of the actual retpoline implementation. While I haven't finished the verification that no more non-indirect calls remain, I have confirmed that we properly are always building with the right names in this case.
Finally, I went through and ran the gcc test suite. The results I had before were:
After, I had:
Going through the differences between the tests, I was able to observe that the indirect-extern thunk tests now passed. The other thunk tests failed in the same way as before, which was part of the goal -- to make sure that they weren't impacted.