| Message ID | 20210323203946.2159693-13-samitolvanen@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add support for Clang CFI | expand |
On Tue, Mar 23, 2021 at 01:39:41PM -0700, Sami Tolvanen wrote: > With CONFIG_CFI_CLANG, the compiler replaces function addresses in > instrumented C code with jump table addresses. This change implements > the __va_function() macro, which returns the actual function address > instead. > > Signed-off-by: Sami Tolvanen <samitolvanen@google.com> > Reviewed-by: Kees Cook <keescook@chromium.org> Is there really no attribute or builtin that can be used to do this without assembly? IIUC from other patches the symbol tables will contain the "real" non-cfi entry points (unless we explciitly asked to make the jump table address canonical), so AFAICT here the compiler should have all the necessary information to generate either the CFI or non-CFI entry point addresses, even if it doesn't expose an interface for that today. It'd be a lot nicer if we could get the compiler to do this for us. Thanks, Mark. > --- > arch/arm64/include/asm/memory.h | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index 0aabc3be9a75..9a4887808681 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -321,6 +321,21 @@ static inline void *phys_to_virt(phys_addr_t x) > #define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x))) > #define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x)) > > +#ifdef CONFIG_CFI_CLANG > +/* > + * With CONFIG_CFI_CLANG, the compiler replaces function address > + * references with the address of the function's CFI jump table > + * entry. The __va_function macro always returns the address of the > + * actual function instead. > + */ > +#define __va_function(x) ({ \ > + void *addr; \ > + asm("adrp %0, " __stringify(x) "\n\t" \ > + "add %0, %0, :lo12:" __stringify(x) : "=r" (addr)); \ > + addr; \ > +}) > +#endif > + > /* > * virt_to_page(x) convert a _valid_ virtual address to struct page * > * virt_addr_valid(x) indicates whether a virtual address is valid > -- > 2.31.0.291.g576ba9dcdaf-goog >
On Thu, Mar 25, 2021 at 3:38 AM Mark Rutland <mark.rutland@arm.com> wrote: > > On Tue, Mar 23, 2021 at 01:39:41PM -0700, Sami Tolvanen wrote: > > With CONFIG_CFI_CLANG, the compiler replaces function addresses in > > instrumented C code with jump table addresses. This change implements > > the __va_function() macro, which returns the actual function address > > instead. > > > > Signed-off-by: Sami Tolvanen <samitolvanen@google.com> > > Reviewed-by: Kees Cook <keescook@chromium.org> > > Is there really no attribute or builtin that can be used to do this > without assembly? I don't think the compiler currently offers anything that could help us here. Peter, can you think of another way to avoid the function address to jump table address conversion with -fno-sanitize-cfi-canonical-jump-tables? > IIUC from other patches the symbol tables will contain the "real" > non-cfi entry points (unless we explciitly asked to make the jump table > address canonical), so AFAICT here the compiler should have all the > necessary information to generate either the CFI or non-CFI entry point > addresses, even if it doesn't expose an interface for that today. > > It'd be a lot nicer if we could get the compiler to do this for us. I agree, that would be quite useful in the kernel. Sami
On Thu, Mar 25, 2021 at 4:28 PM Sami Tolvanen <samitolvanen@google.com> wrote: > > On Thu, Mar 25, 2021 at 3:38 AM Mark Rutland <mark.rutland@arm.com> wrote: > > > > On Tue, Mar 23, 2021 at 01:39:41PM -0700, Sami Tolvanen wrote: > > > With CONFIG_CFI_CLANG, the compiler replaces function addresses in > > > instrumented C code with jump table addresses. This change implements > > > the __va_function() macro, which returns the actual function address > > > instead. > > > > > > Signed-off-by: Sami Tolvanen <samitolvanen@google.com> > > > Reviewed-by: Kees Cook <keescook@chromium.org> > > > > Is there really no attribute or builtin that can be used to do this > > without assembly? > > I don't think the compiler currently offers anything that could help > us here. Peter, can you think of another way to avoid the function > address to jump table address conversion with > -fno-sanitize-cfi-canonical-jump-tables? No, the assembly seems like the best way at the moment. > > IIUC from other patches the symbol tables will contain the "real" > > non-cfi entry points (unless we explciitly asked to make the jump table > > address canonical), so AFAICT here the compiler should have all the > > necessary information to generate either the CFI or non-CFI entry point > > addresses, even if it doesn't expose an interface for that today. > > > > It'd be a lot nicer if we could get the compiler to do this for us. > > I agree, that would be quite useful in the kernel. Maybe. The kernel's requirements seem quite specialized here though. A normal C or C++ program has little need for the actual entry point, so if you need it you are probably doing something low level enough to require assembly anyway. Peter
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h index 0aabc3be9a75..9a4887808681 100644 --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -321,6 +321,21 @@ static inline void *phys_to_virt(phys_addr_t x) #define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x))) #define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x)) +#ifdef CONFIG_CFI_CLANG +/* + * With CONFIG_CFI_CLANG, the compiler replaces function address + * references with the address of the function's CFI jump table + * entry. The __va_function macro always returns the address of the + * actual function instead. + */ +#define __va_function(x) ({ \ + void *addr; \ + asm("adrp %0, " __stringify(x) "\n\t" \ + "add %0, %0, :lo12:" __stringify(x) : "=r" (addr)); \ + addr; \ +}) +#endif + /* * virt_to_page(x) convert a _valid_ virtual address to struct page * * virt_addr_valid(x) indicates whether a virtual address is valid