All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sourabh Jain <sourabhjain@linux.ibm.com>
To: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
	linuxppc-dev@lists.ozlabs.org
Cc: Aditya Gupta <adityag@linux.ibm.com>,
	Daniel Axtens <dja@axtens.net>,
	Hari Bathini <hbathini@linux.ibm.com>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Mahesh Salgaonkar <mahesh@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Shivang Upadhyay <shivangu@linux.ibm.com>,
	Venkat Rao Bagalkote <venkat88@linux.ibm.com>,
	Aboorva Devarajan <aboorvad@linux.ibm.com>
Subject: Re: [PATCH 2/2] powerpc/kexec: Disable KASAN for VMX helpers used in MMU-off path
Date: Thu, 2 Apr 2026 09:29:16 +0530	[thread overview]
Message-ID: <255cc5b6-e1f3-4fc7-b100-5db4635a04eb@linux.ibm.com> (raw)
In-Reply-To: <wlyvmo0a.ritesh.list@gmail.com>



On 29/03/26 06:48, Ritesh Harjani (IBM) wrote:
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> The kexec sequence invokes enter_vmx_ops() and exit_vmx_ops() with the
>> MMU disabled. In this context, code must not rely on normal virtual
>> address translations or trigger page faults.
>> With KASAN enabled, these functions get instrumented and may access
>> shadow memory using regular address translation. When executed with
>> the MMU off, this can lead to page faults (bad_page_fault) from which
>> the kernel cannot recover in the kexec path, resulting in a hang.
> Right, so with mmu off, kernel can't access KASAN shadow memory.
>
> So, let me trace down the path a bit... you skipped an important detail
> i.e. preempt_count() is always inline, and we play a few tricks in kexec
> path to tell enter_vmx_ops() that we are in HARDIRQ mode.
>
> default_machine_kexec(image)
>      current_thread_info()->preempt_count = HARDIRQ_OFFSET
>
>      kexec_sequence(..., copy_with_mmu_off = 1)
>          if (copy_with_mmu_off) bl real_mode
>
>          bl kexec_copy_flush(image)
>              memcpy(ranges, image->segment, ...)
>
>              copy_segments()
>                  copy_page(dest, addr)
>
>                      bl enter_vmx_ops()
>                          if (in_interrupt() == true) return 0 // preempt_count == HARDIRQ_OFFSET
>                      beq .Lnonvmx_copy

Yes since preempt_count for the current thread is set to HARDIRQ_OFFSET 
we return early from copy_page() -> copypage_power7 -> enter_vmx_ops() 
and call to exit_vmx_ops is skipped.
>
>> Mark enter_vmx_ops() and exit_vmx_ops() with __no_sanitize_address to
>> avoid KASAN instrumentation and ensure kexec boots fine with KASAN
>> enabled.
>>
> IIUC, preempt_count() is always inline, and since you are disabling kasan
> instrumentation on enter_vmx_ops(), hence it just works for this reason.
> But you missed adding that detail here.

Yeah it is worth adding that in commit message. I will add it in v2.

>
> enter_vmx_ops()
>      if (in_interrupt()) // return 0
>             preempt_count() & ... | HARDIRQ_OFFSET   // preempt_count() is this is __always_inline
>
> static __always_inline int preempt_count(void)
> {
> 	return READ_ONCE(current_thread_info()->preempt_count);
> }
>
>> Cc: Aditya Gupta <adityag@linux.ibm.com>
>> Cc: Daniel Axtens <dja@axtens.net>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
>> Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
>> Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>>   arch/powerpc/lib/vmx-helper.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
>> index 554b248002b4..c01b2d856650 100644
>> --- a/arch/powerpc/lib/vmx-helper.c
>> +++ b/arch/powerpc/lib/vmx-helper.c
>> @@ -52,7 +52,7 @@ int exit_vmx_usercopy(void)
>>   }
>>   EXPORT_SYMBOL(exit_vmx_usercopy);
>>   
>> -int enter_vmx_ops(void)
> In that case, should we should add a comment here saying:
>
> /*
>   * Can be called from kexec copy_page() path with MMU off. The kexec
>   * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
>   * Since in_interrupt() is always inline, __no_sanitize_address on this
>   * function is sufficient to avoid KASAN shadow memory accesses in real
>   * mode.
>   */

Thanks for the write up, I will add it in v2.

>> +int __no_sanitize_address enter_vmx_ops(void)
>>   {
>>   	if (in_interrupt())
>>   		return 0;
>> @@ -69,7 +69,7 @@ int enter_vmx_ops(void)
>>    * passed a pointer to the destination which we return as required by a
>>    * memcpy implementation.
>>    */
>> -void *exit_vmx_ops(void *dest)
>> +void __no_sanitize_address *exit_vmx_ops(void *dest)
> I am assuming since we never enter into VMX in kexec path, so kexec path
> must not be calling exit_vmx_ops anyways? So do we need __no_sanitize_address here?

Agree in copypage_power7() we jump to  .Lnonvmx_copy label and do
not call exit_vmx_ops. I will remove __no_sanitize_address from 
exit_vmx_ops().

Thanks for the detailed review Ritesh.

- Soruabh Jain


  parent reply	other threads:[~2026-04-02  3:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-21  5:31 [PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o Sourabh Jain
2026-03-21  5:31 ` [PATCH 2/2] powerpc/kexec: Disable KASAN for VMX helpers used in MMU-off path Sourabh Jain
2026-03-29  1:18   ` Ritesh Harjani
2026-04-02  0:04     ` Ritesh Harjani
2026-04-02  3:59     ` Sourabh Jain [this message]
2026-03-23  6:11 ` [PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o Mahesh J Salgaonkar
2026-03-23 10:36   ` Sourabh Jain
2026-03-23  8:53 ` Venkat Rao Bagalkote
2026-03-29  1:56 ` Ritesh Harjani
2026-04-01 13:42   ` Sourabh Jain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=255cc5b6-e1f3-4fc7-b100-5db4635a04eb@linux.ibm.com \
    --to=sourabhjain@linux.ibm.com \
    --cc=aboorvad@linux.ibm.com \
    --cc=adityag@linux.ibm.com \
    --cc=dja@axtens.net \
    --cc=hbathini@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mahesh@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=ritesh.list@gmail.com \
    --cc=shivangu@linux.ibm.com \
    --cc=venkat88@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.