KASAN issues with idle / hotplug area
Mark Rutland
mark.rutland at arm.com
Thu Feb 18 03:15:16 PST 2016
On Thu, Feb 18, 2016 at 11:22:24AM +0300, Andrey Ryabinin wrote:
>
> On 02/17/2016 10:16 PM, Mark Rutland wrote:
> > Looking at the assembly, functions seem to get instrumented regardless
> > of the __no_sanitize_address annotation. The assembly of
> > __invoke_psci_fn_{smc,hvc} look identical, even if one has the
> > annotation and one does not.
> >
> > In the case below, it looks like __invoke_psci_fn_hvc is storing to the
> > shadow area even though it's anotated with __no_sanitize_address. Note
> > that the adrp symbol resolution is bogus; psci_to_linux_errno happens to
> > be at offset 0 in the as-yet unlinked psci.o object.
> >
>
> ...
> > I also tried using __attribute__((no_sanitize_address)) directly, in
> > case there was some header issue, but that doesn't seem to be the case.
> >
> > I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
> > confirm whether they see the same? Does the same happen for x86?
>
> Confirming, this happens on every GCC I have (including x86).
> It seems that 'no_sanitize_address' in gcc removes only memory access checks
> but it doesn't remove stack redzones.
> I think this is wrong, e.g. clang removes instrumentation completely. I'll submit a bug.
Ok.
Unless there's some clever trickery that we can employ, the above
renders the Linux __no_sanitize_address annotation useless for this
style of code.
We should certianly call that out in the commentary in
include/linux/compiler-gcc.h.
> But we need fix this in kernel.
> I see two options here:
> * completely disable instrumentation for drivers/firmware/psci.c
This is somewhat overkill, and we'd also have to disable instrumentation
for arch/arm64/kernel/psci.c (for psci_suspend_finisher).
I would like to have instrumentation for everything we can safely
instrument.
This is probably the least worst option, though.
> * get back to assembly implementation
We'd also have to convert psci_suspend_finisher and psci_cpu_suspend,
the latter being generic code. That goes against the consolidation we
were aiming for.
Mark.
More information about the linux-arm-kernel
mailing list