[PATCH] D84414: [RISCV] Support Shadow Call Stack

Sam Elliott via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 24 11:13:40 PDT 2020


lenary added a comment.

In D84414#2234255 <https://reviews.llvm.org/D84414#2234255>, @zzheng wrote:

> In D84414#2234112 <https://reviews.llvm.org/D84414#2234112>, @lenary wrote:
>
>> Why do we have to pass `-ffixed-x18` when compiling? Is it enough to just reserve `x18` whenever the function has the shadow call stack attribute?
>
> When SCS is on, x18 must be preserved across calls. Given it's a callee-saved, value in x18 is preserved by functions that do not have SCS attribute.
>
> However, saving x18 on stack risks leaking SCS's location in memory, making the defense useless.

Ok, so any compilation units without `-fsanitize=shadow-call-stack` should be compiled with `-ffixed-x18` if you want to link those together. That is reasonable. My question was whether we can ensure that `-fsanitize=shadow-call-stack` can imply `-ffixed-x18` rather than having to pass both options.

It is my understanding that all functions in a CU with `-fsanitize=shadow-call-stack` will get the SCS function attribute, so why can't we use that attribute to work out whether x18 should be reserved, rather than using `-ffixed-x18`? You'll see `RISCVRegisterInfo::getReservedRegs` reserves `fp` and `bp` only if they're needed by the function (which can be based on attributes or other info), rather than using `isRegisterReservedByUser` - which seems cleaner to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84414



More information about the llvm-commits mailing list