[PATCH] D51157: [x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative Load Hardening.

Chandler Carruth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Aug 23 23:57:43 PDT 2018


chandlerc marked an inline comment as done.
chandlerc added inline comments.


================
Comment at: llvm/docs/LangRef.rst:1659-1661
+    that hardening. It should also be possible to *not* harden a hot and/or safe
+    function and have code inlined there *not* be hardened (even if the generic
+    form is hardened).
----------------
kristof.beyls wrote:
> It feels wrong to me to have source code that is annotated to get hardened, but that actually will not get hardened (whether it is due to it being inlined somewhere or due to any other automatic behind-the-back-of-the-developer transformation). I fear this may lower trust in the protection this attribute provides.
> I assume there is a use case where the developer wants to indicate "no hardening in this function nor in any functions inlined here". If that needs to be supported, my feel is that we may need to support that in another way.
> I guess that there must be some cases where just duplicating the function to be inlined in the source code into a hardened and a non-hardened version could be too hard to do for some programs.
> So, in short, I don't know what the best solution here is. I just want to raise my concern that I don't think it's a good idea that functions that are marked to be hardened end up not getting hardened under some circumstances.
I actually started out with this, so I'm very sympathetic to the perspective.

Given that you prefer it, let's start with this very conservative stance. We can always add specific mechanisms to be less conservative later, but I agree that it seems much better to start with a safe position.


Repository:
  rL LLVM

https://reviews.llvm.org/D51157





More information about the cfe-commits mailing list