Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH] lkdtm: fix memory copy size for WRITE_KERN | Date | Tue, 26 Jan 2021 22:53:31 +0000 |
| |
From: Nick Desaulniers > Sent: 26 January 2021 18:40 > > On Tue, Jan 26, 2021 at 6:13 AM Candle Sun <candlesea@gmail.com> wrote: > > > > On Mon, Jan 25, 2021 at 6:37 PM David Laight <David.Laight@aculab.com> wrote: > > > > > > From: Candle Sun > > > > Sent: 25 January 2021 08:56 > > > > > > > > From: Candle Sun <candle.sun@unisoc.com> > > > > > > > > Though do_overwritten() follows do_nothing() in source code, the final > > > > memory address order is determined by compiler. We can't always assume > > > > address of do_overwritten() is bigger than do_nothing(). At least the > > > > Clang we are using places do_overwritten() before do_nothing() in the > > > > object. This causes the copy size in lkdtm_WRITE_KERN() is *really* > > > > big and WRITE_KERN test on ARM32 arch will fail. > > > > > > > > Compare the address order before doing the subtraction. > > > > > > It isn't clear that helps. > > > Compile with -ffunction-sections and/or do LTO an there > > > is no reason at all why the functions should be together. > > > > > > Even without that lkdtm_WRITE_KERN() could easily be between them. > > > > > > You need to get the size of the 'empty function' from the > > > symbol table. > > > > > > David > > > > Thanks David. > > > > I think using abs() by Nick's advice would be better. But could you > > point out which kernel function can get function size? > > The Elf symbol table should contain this info, IIUC. > > Given a string literal of a symbol (such as a function identifier), > kallsyms_lookup_name() can be used to return its address. > > From there we'd want to fetch the Elf_Sym for the address which should > contain a st_size field which I think corresponds to the size in bytes > of the function. (At least, from playing with `llvm-readelf -s`) > Probably would want to validate it's an STT_FUNC symbol type, too. We > basically want something like kexec_purgatory_find_symbol(), but that > knows about the entire kernel image, and not the purgatory image used > during kexec. I don't see any such function currently in the > kernel...but it's a large codebase to search through.
The alternative is to get the linker script to define a specific constant to the size of the function. You can then link against it (by using it as the address of a symbol).
It may be easier to use an asm file for the 'return 0' code. I'm guessing there are things in the static branch area that could be used.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |