Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Daniel Axtens <dja@axtens.net>
To:     Christophe Leroy <christophe.leroy@csgroup.eu>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com,
        aneesh.kumar@linux.ibm.com, bsingharora@gmail.com
Subject: Re: [PATCH v10 6/6] powerpc: Book3S 64-bit outline-only KASAN support
In-Reply-To: <4b790789-052f-76de-a289-726517026efd@csgroup.eu>
References: <20210203115946.663273-1-dja@axtens.net> <20210203115946.663273-7-dja@axtens.net> <4b790789-052f-76de-a289-726517026efd@csgroup.eu>
Date:   Wed, 03 Feb 2021 23:53:17 +1100
Message-ID: <875z39wbwi.fsf@dja-thinkpad.axtens.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Christophe Leroy <christophe.leroy@csgroup.eu> writes:

> Le 03/02/2021 =C3=A0 12:59, Daniel Axtens a =C3=A9crit=C2=A0:
>> Implement a limited form of KASAN for Book3S 64-bit machines running und=
er
>> the Radix MMU, supporting only outline mode.
>>=20
>
>> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process=
.c
>> index a66f435dabbf..9a6fd603f0e7 100644
>> --- a/arch/powerpc/kernel/process.c
>> +++ b/arch/powerpc/kernel/process.c
>> @@ -2157,8 +2157,8 @@ void show_stack(struct task_struct *tsk, unsigned =
long *stack,
>>   			break;
>>=20=20=20
>>   		stack =3D (unsigned long *) sp;
>> -		newsp =3D stack[0];
>> -		ip =3D stack[STACK_FRAME_LR_SAVE];
>> +		newsp =3D READ_ONCE_NOCHECK(stack[0]);
>> +		ip =3D READ_ONCE_NOCHECK(stack[STACK_FRAME_LR_SAVE]);
>>   		if (!firstframe || ip !=3D lr) {
>>   			printk("%s["REG"] ["REG"] %pS",
>>   				loglvl, sp, ip, (void *)ip);
>> @@ -2176,17 +2176,19 @@ void show_stack(struct task_struct *tsk, unsigne=
d long *stack,
>>   		 * See if this is an exception frame.
>>   		 * We look for the "regshere" marker in the current frame.
>>   		 */
>> -		if (validate_sp(sp, tsk, STACK_INT_FRAME_SIZE)
>> -		    && stack[STACK_FRAME_MARKER] =3D=3D STACK_FRAME_REGS_MARKER) {
>> +		if (validate_sp(sp, tsk, STACK_INT_FRAME_SIZE) &&
>> +		    (READ_ONCE_NOCHECK(stack[STACK_FRAME_MARKER]) =3D=3D
>> +		     STACK_FRAME_REGS_MARKER)) {
>>   			struct pt_regs *regs =3D (struct pt_regs *)
>>   				(sp + STACK_FRAME_OVERHEAD);
>>=20=20=20
>> -			lr =3D regs->link;
>> +			lr =3D READ_ONCE_NOCHECK(regs->link);
>>   			printk("%s--- interrupt: %lx at %pS\n",
>> -			       loglvl, regs->trap, (void *)regs->nip);
>> +			       loglvl, READ_ONCE_NOCHECK(regs->trap),
>> +			       (void *)READ_ONCE_NOCHECK(regs->nip));
>>   			__show_regs(regs);
>>   			printk("%s--- interrupt: %lx\n",
>> -			       loglvl, regs->trap);
>> +			       loglvl, READ_ONCE_NOCHECK(regs->trap));
>>=20=20=20
>>   			firstframe =3D 1;
>>   		}
>
>
> The above changes look like a bug fix not directly related to KASAN. Shou=
ld be split out in another=20
> patch I think.

That code corresponds to the following part of the patch description:

| - Make our stack-walking code KASAN-safe by using READ_ONCE_NOCHECK -
|   generic code, arm64, s390 and x86 all do this for similar sorts of
|   reasons: when unwinding a stack, we might touch memory that KASAN has
|   marked as being out-of-bounds. In our case we often get this when
|   checking for an exception frame because we're checking an arbitrary
|   offset into the stack frame.
|
|   See commit 20955746320e ("s390/kasan: avoid false positives during stack
|   unwind"), commit bcaf669b4bdb ("arm64: disable kasan when accessing
|   frame->fp in unwind_frame"), commit 91e08ab0c851 ("x86/dumpstack:
|   Prevent KASAN false positive warnings") and commit 6e22c8366416
|   ("tracing, kasan: Silence Kasan warning in check_stack of stack_tracer")

include/linux/compiler.h describes it as follows:

/*
 * Use READ_ONCE_NOCHECK() instead of READ_ONCE() if you need
 * to hide memory access from KASAN.
 */

So I think it is sufficently connected with KASAN to be in this patch.

Kind regards,
Daniel

>
> Christophe