Re: [PATCH] lkdtm: don't move ctors to .rodata

[Kees Cook]

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