Re: [PATCH] lkdtm: don't move ctors to .rodata
From: Kees Cook
Date: Tue Dec 08 2020 - 16:22:14 EST
On Mon, Dec 07, 2020 at 05:05:33PM +0000, Mark Rutland wrote:
> When building with KASAN and LKDTM, clang may implictly generate an
> asan.module_ctor function in the LKDTM rodata object. The Makefile moves
> the lkdtm_rodata_do_nothing() function into .rodata by renaming the
> file's .text section to .rodata, and consequently also moves the ctor
> function into .rodata, leading to a boot time crash (splat below) when
> the ctor is invoked by do_ctors().
>
> Let's prevent this by marking the function as noinstr rather than
> notrace, and renaming the file's .noinstr.text to .rodata. Marking the
> function as noinstr will prevent tracing and kprobes, and will inhibit
> any undesireable compiler instrumentation.
>
> The ctor function (if any) will be placed in .text and will work
> correctly.
>
> Example splat before this patch is applied:
>
> [ 0.916359] Unable to handle kernel execute from non-executable memory at virtual address ffffa0006b60f5ac
> [ 0.922088] Mem abort info:
> [ 0.922828] ESR = 0x8600000e
> [ 0.923635] EC = 0x21: IABT (current EL), IL = 32 bits
> [ 0.925036] SET = 0, FnV = 0
> [ 0.925838] EA = 0, S1PTW = 0
> [ 0.926714] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000427b3000
> [ 0.928489] [ffffa0006b60f5ac] pgd=000000023ffff003, p4d=000000023ffff003, pud=000000023fffe003, pmd=0068000042000f01
> [ 0.931330] Internal error: Oops: 8600000e [#1] PREEMPT SMP
> [ 0.932806] Modules linked in:
> [ 0.933617] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-rc7 #2
> [ 0.935620] Hardware name: linux,dummy-virt (DT)
> [ 0.936924] pstate: 40400005 (nZcv daif +PAN -UAO -TCO BTYPE=--)
> [ 0.938609] pc : asan.module_ctor+0x0/0x14
> [ 0.939759] lr : do_basic_setup+0x4c/0x70
> [ 0.940889] sp : ffff27b600177e30
> [ 0.941815] x29: ffff27b600177e30 x28: 0000000000000000
> [ 0.943306] x27: 0000000000000000 x26: 0000000000000000
> [ 0.944803] x25: 0000000000000000 x24: 0000000000000000
> [ 0.946289] x23: 0000000000000001 x22: 0000000000000000
> [ 0.947777] x21: ffffa0006bf4a890 x20: ffffa0006befb6c0
> [ 0.949271] x19: ffffa0006bef9358 x18: 0000000000000068
> [ 0.950756] x17: fffffffffffffff8 x16: 0000000000000000
> [ 0.952246] x15: 0000000000000000 x14: 0000000000000000
> [ 0.953734] x13: 00000000838a16d5 x12: 0000000000000001
> [ 0.955223] x11: ffff94000da74041 x10: dfffa00000000000
> [ 0.956715] x9 : 0000000000000000 x8 : ffffa0006b60f5ac
> [ 0.958199] x7 : f9f9f9f9f9f9f9f9 x6 : 000000000000003f
> [ 0.959683] x5 : 0000000000000040 x4 : 0000000000000000
> [ 0.961178] x3 : ffffa0006bdc15a0 x2 : 0000000000000005
> [ 0.962662] x1 : 00000000000000f9 x0 : ffffa0006bef9350
> [ 0.964155] Call trace:
> [ 0.964844] asan.module_ctor+0x0/0x14
> [ 0.965895] kernel_init_freeable+0x158/0x198
> [ 0.967115] kernel_init+0x14/0x19c
> [ 0.968104] ret_from_fork+0x10/0x30
> [ 0.969110] Code: 00000003 00000000 00000000 00000000 (00000000)
> [ 0.970815] ---[ end trace b5339784e20d015c ]---
>
> Signed-off-by: Mark Rutland <mark.rutland@xxxxxxx>
Oh, eek. Why was a ctor generated at all? But yes, this looks good.
Greg, can you pick this up please?
Acked-by: Kees Cook <keescook@xxxxxxxxxxxx>
--
Kees Cook