linux-kernel - Re: [PATCH 1/2] KVM: arm64: Dump instruction on hyp panic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aL7JLbljvX1JATP3@willie-the-truck>
Date: Mon, 8 Sep 2025 13:16:45 +0100
From: Will Deacon <will@...nel.org>
To: Mostafa Saleh <smostafa@...gle.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kvmarm@...ts.linux.dev, catalin.marinas@....com, maz@...nel.org,
	oliver.upton@...ux.dev, joey.gouly@....com, suzuki.poulose@....com,
	yuzenghui@...wei.com, qperret@...gle.com, keirf@...gle.com
Subject: Re: [PATCH 1/2] KVM: arm64: Dump instruction on hyp panic

On Thu, Jul 17, 2025 at 11:47:43PM +0000, Mostafa Saleh wrote:
> Similar to the kernel panic, where the instruction code is printed,
> we can do the same for hypervisor panics.
> 
> This patch does that only in case of “CONFIG_NVHE_EL2_DEBUG” or nvhe.
> 
> The next patch adds support for pKVM.
> 
> Also, remove the hardcoded argument dump_kernel_instr().
> 
> Signed-off-by: Mostafa Saleh <smostafa@...gle.com>
> ---
>  arch/arm64/include/asm/traps.h |  1 +
>  arch/arm64/kernel/traps.c      | 20 +++++++++++++-------
>  arch/arm64/kvm/handle_exit.c   |  5 +++++
>  3 files changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
> index 82cf1f879c61..0d7e86a95d62 100644
> --- a/arch/arm64/include/asm/traps.h
> +++ b/arch/arm64/include/asm/traps.h
> @@ -30,6 +30,7 @@ void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *
>  void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
>  
>  int early_brk64(unsigned long addr, unsigned long esr, struct pt_regs *regs);
> +void dump_instr(unsigned long addr);
>  
>  /*
>   * Move regs->pc to next instruction and do necessary setup before it
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 9bfa5c944379..d692c05e3686 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -149,15 +149,11 @@ pstate_check_t * const aarch32_opcode_cond_checks[16] = {
>  
>  int show_unhandled_signals = 0;
>  
> -static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
> +void dump_instr(unsigned long addr)
>  {
> -	unsigned long addr = instruction_pointer(regs);
>  	char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str;
>  	int i;
>  
> -	if (user_mode(regs))
> -		return;
> -
>  	for (i = -4; i < 1; i++) {
>  		unsigned int val, bad;

I'm a little worried that this function might be used to try and dump
instructions from userspace now that it just takes an address.

Maybe we could:

  - Keep the name unchanged, e.g. void dump_kernel_instr(unsigned long kaddr)
  - Inline the user_mode(regs) and instruction_pointer(regs) calls into
    __die()
  - Check is_ttbr1_addr(kaddr) in dump_kernel_instr()

WDYT?

Will