| Message ID | 20191101221150.116536-11-samitolvanen@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | add support for Clang's Shadow Call Stack | expand |
On Fri, Nov 01, 2019 at 03:11:43PM -0700, Sami Tolvanen wrote: > With CONFIG_KRETPROBES, function return addresses are modified to > redirect control flow to kretprobe_trampoline. This is incompatible > with SCS. I'm a bit confused as to why that's the case -- could you please elaborate on how this is incompatible? IIUC kretrobes works by patching the function entry point with a BRK, so that it can modify the LR _before_ it is saved to the stack. I don't see how SCS affects that. When the instrumented function returns, it'll balance its SCS state, then "return" to kretprobe_trampoline. Since kretprobe_trampoline is plain assembly, it doesn't have SCS, and can modify the LR live, as it does. So functionally, that appears to work. What am I missing? Thanks, Mark. > Signed-off-by: Sami Tolvanen <samitolvanen@google.com> > Reviewed-by: Kees Cook <keescook@chromium.org> > --- > arch/arm64/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 3f047afb982c..e7b57a8a5531 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -165,7 +165,7 @@ config ARM64 > select HAVE_STACKPROTECTOR > select HAVE_SYSCALL_TRACEPOINTS > select HAVE_KPROBES > - select HAVE_KRETPROBES > + select HAVE_KRETPROBES if !SHADOW_CALL_STACK > select HAVE_GENERIC_VDSO > select IOMMU_DMA if IOMMU_SUPPORT > select IRQ_DOMAIN > -- > 2.24.0.rc1.363.gb1bccd3e3d-goog >
On Mon, Nov 4, 2019 at 9:05 AM Mark Rutland <mark.rutland@arm.com> wrote: > I'm a bit confused as to why that's the case -- could you please > elaborate on how this is incompatible? > > IIUC kretrobes works by patching the function entry point with a BRK, so > that it can modify the LR _before_ it is saved to the stack. I don't see > how SCS affects that. You're correct. While this may not be optimal for reducing attack surface, I just tested this to confirm that there's no functional conflict. I'll drop this and related patches from v5. Sami
On Mon, Nov 04, 2019 at 03:42:09PM -0800, Sami Tolvanen wrote: > On Mon, Nov 4, 2019 at 9:05 AM Mark Rutland <mark.rutland@arm.com> wrote: > > I'm a bit confused as to why that's the case -- could you please > > elaborate on how this is incompatible? > > > > IIUC kretrobes works by patching the function entry point with a BRK, so > > that it can modify the LR _before_ it is saved to the stack. I don't see > > how SCS affects that. > > You're correct. While this may not be optimal for reducing attack > surface, I just tested this to confirm that there's no functional > conflict. I'll drop this and related patches from v5. Great; thanks for confirming! Mark.
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3f047afb982c..e7b57a8a5531 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -165,7 +165,7 @@ config ARM64 select HAVE_STACKPROTECTOR select HAVE_SYSCALL_TRACEPOINTS select HAVE_KPROBES - select HAVE_KRETPROBES + select HAVE_KRETPROBES if !SHADOW_CALL_STACK select HAVE_GENERIC_VDSO select IOMMU_DMA if IOMMU_SUPPORT select IRQ_DOMAIN