soc: qcom: scm: Skip Kasan sanitization of the SCM driver

SCM (Secure Channel Manager) driver is used to communicate
with the secure world entities like trustzone and hypervisor.

As a part of the communication we expect to give certain
input, output operands and the caller of the scm_callX
API would expect that output values or return values
of the scm_callX should not get corrupted (if they depend on it).

Due to Kasan instrumentation of the SCM driver following
code is getting instrumented with Kasan __asan_store8_noabort
APIs which would internally check if the memory access is allowed
and it is the functionality of the Kasan to check/instrument
the load and stores.

if (ret1)
	*ret1 = r1;

if (ret2)
	*ret2 = r2;

if (ret3)
	*ret3 = r2;

All will be fine for the first *ret1 = r1; execution since
GCC has generated the code which saves the x1 value (r1)
into the another register but the execution of the
__asan_store8_noabort API after the saving of the register
corrupts the x2 and x3 when it returns. GCC has no knowledge
at this point to save the x2 and x3.

Due to this x2 and x3 is loaded with the Kasan shadow
offset value and Kasan shifted (>> 3) address.

Since x2 and x3 (r2 and r3 in the code above) would be used
as the ret2 and ret3 for the caller of the scm_callX API
the caller would get the wrong return values (if it needs them).

QSEECOM is one such driver which uses these ret2 and ret3 values
and due to this corruption QSEECOM driver was treating it as
SCM call failure, though the bug described above due to Kasan
instrumentation would be applicable to any caller needing
the right values of the ret2 and ret3.

SCM driver is very small and simple and we would not expect
the Out of bound or use-after-free errors for it, so it would
be fine to skip it from the Kasan instrumentation.

Change-Id: I8b2a17759295375c21abc520110f855f349faf4b
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
Signed-off-by: Sridhar Parasuram <sridhar@codeaurora.org>