[RFC] Support for KASLR

[RFC] Support for KASLR

[Torsten Polle]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

Hi,

I’ve a kernel with the configuration option CONFIG_RANDOMIZE_BASE set. The backtrace fails for the kernel. The patch tries to address this issue. 

The patch is more a proof of concept. But so far, I’ve not found a better way to locate the relocated start address of the kernel than to take the value of s->static_addr, which holds the address of the symbol _stext.

Regards,
Torsten

[-- Attachment #2: 0001-runtime-unwind.c-Support-KASLR.patch --]
[-- Type: application/octet-stream, Size: 1194 bytes --]

From 06250a10f7aa775cd8e08e65c18eeb71d27086a6 Mon Sep 17 00:00:00 2001
From: Torsten Polle <Torsten.Polle@gmx.de>
Date: Mon, 19 Mar 2018 21:37:25 +0100
Subject: [PATCH] runtime/unwind.c: Support KASLR.

---
 runtime/unwind.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/runtime/unwind.c b/runtime/unwind.c
index ec7cd58..5fc4ad4 100644
--- a/runtime/unwind.c
+++ b/runtime/unwind.c
@@ -724,10 +724,13 @@ adjustStartLoc (unsigned long startLoc,
   dbug_unwind(2, "adjustStartLoc=%lx, ptrType=%s, m=%s, s=%s eh=%d\n",
 	      startLoc, _stp_eh_enc_name(ptrType), m->path, s->name, is_ehframe);
   if (startLoc == 0
-      || strcmp (m->name, "kernel")  == 0
       || (strcmp (s->name, ".absolute") == 0 && !is_ehframe))
     return startLoc;
 
+  /* Even the kernel might have been relocated due to KASLR. */
+  if (strcmp (m->name, "kernel")  == 0)
+    return startLoc + (s->static_addr & ~0x1fffff) - s->sec_load_offset;
+
   /* eh_frame data has been loaded in the kernel, so readjust offset. */
   if (is_ehframe) {
     dbug_unwind(2, "eh_frame=%lx, eh_frame_addr=%lx\n", (unsigned long) m->eh_frame, m->eh_frame_addr);
-- 
2.7.4

Re: [RFC] Support for KASLR

[Frank Ch. Eigler]

Hi, Torsten -

> [...]
> I’ve a kernel with the configuration option CONFIG_RANDOMIZE_BASE
> set. The backtrace fails for the kernel. The patch tries to address
> this issue. [...]
> _stext.

It would surprise for systemtap to need this sort of thing now.  KASLR
is a years-old technique, and CONFIG_RANDOMIZE_BASE has been default for
most of that time.  We routinely relocate our internal kernel
symbol/unwind info with respect to the same _stext symbol.  I wonder
what is going on.

- FChE

Re: [RFC] Support for KASLR

[Torsten Polle]

> Am 20.03.2018 um 14:22 schrieb Frank Ch. Eigler <fche@redhat.com>:
> 
> 
> Hi, Torsten -
> 
>> [...]
>> I’ve a kernel with the configuration option CONFIG_RANDOMIZE_BASE
>> set. The backtrace fails for the kernel. The patch tries to address
>> this issue. [...]
>> _stext.
> 
> It would surprise for systemtap to need this sort of thing now.  KASLR
> is a years-old technique, and CONFIG_RANDOMIZE_BASE has been default for
> most of that time.  We routinely relocate our internal kernel
> symbol/unwind info with respect to the same _stext symbol.  I wonder
> what is going on.
> 
> - FChE

Hi Frank,

The reason is that the backtrace operation has so many failsafe paths that it works most of the time. ;-)

I double checked my observation. I can confirm that e.g print_backtrace() works fine even with CONFIG_RANDOMIZE_BASE set. What fails in my case is a hack that I had added to one of my systemtap scripts. The script uses the function _stp_stack_kernel_get() without going through _stp_stack_kernel_print(). The call to _stp_stack_kernel_get() succeeds for depth = 0, but fails for greater values. _stp_stack_kernel_print() falls back to _stp_stack_print_fallback() (STP_USE_DWARF_UNWINDER is defined in my configuration).

Kind Regards,
Torsten