Re: [PATCH] lkdtm: don't move ctors to .rodata
From: Greg Kroah-Hartman
Date: Wed Dec 09 2020 - 09:50:58 EST
On Tue, Dec 08, 2020 at 01:20:56PM -0800, Kees Cook wrote:
> 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>
Now picked up, thanks.
greg k-h