linux-kernel - Re: [PATCH 6/7] powerpc/traps: Print signal name for unhandled signals

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20180725174927.Horde.Sfg4oyTmcaLgHIJr3Gf-oQ1@messagerie.si.c-s.fr>
Date:   Wed, 25 Jul 2018 17:49:27 +0200
From:   LEROY Christophe <christophe.leroy@....fr>
To:     Murilo Opsfelder Araujo <muriloo@...ux.ibm.com>
Cc:     linuxppc-dev@...ts.ozlabs.org, "Tobin C . Harding" <me@...in.cc>,
        Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
        Simon Guo <wei.guo.simon@...il.com>,
        Paul Mackerras <paulus@...ba.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Michael Neuling <mikey@...ling.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Cyril Bur <cyrilbur@...il.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Balbir Singh <bsingharora@...il.com>,
        Andrew Donnellan <andrew.donnellan@....ibm.com>,
        Alastair D'Silva <alastair@...ilva.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/7] powerpc/traps: Print signal name for unhandled
 signals

Murilo Opsfelder Araujo <muriloo@...ux.ibm.com> a écrit :

> This adds a human-readable name in the unhandled signal message.
>
> Before this patch, a page fault looked like:
>
>     Jul 11 16:04:11 localhost kernel: pandafault[6303]: unhandled  
> signal 11 at 00000000100007d0 nip 000000001000061c lr  
> 00007fff93c55100 code 2 in pandafault[10000000+10000]
>
> After this patch, a page fault looks like:
>
>     Jul 11 18:14:48 localhost kernel: pandafault[6352]: segfault  
> (11) at 000000013a2a09f8 nip 000000013a2a086c lr 00007fffb63e5100  
> code 2 in pandafault[13a2a0000+10000]
>
> Signed-off-by: Murilo Opsfelder Araujo <muriloo@...ux.ibm.com>
> ---
>  arch/powerpc/kernel/traps.c | 43 +++++++++++++++++++++++++++++++++----
>  1 file changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index e6c43ef9fb50..e55ee639d010 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -96,6 +96,41 @@ EXPORT_SYMBOL(__debugger_fault_handler);
>  #define TM_DEBUG(x...) do { } while(0)
>  #endif
>
> +static const char *signames[SIGRTMIN + 1] = {
> +	"UNKNOWN",
> +	"SIGHUP",			// 1
> +	"SIGINT",			// 2
> +	"SIGQUIT",			// 3
> +	"SIGILL",			// 4
> +	"unhandled trap",		// 5 = SIGTRAP
> +	"SIGABRT",			// 6 = SIGIOT
> +	"bus error",			// 7 = SIGBUS
> +	"floating point exception",	// 8 = SIGFPE
> +	"illegal instruction",		// 9 = SIGILL
> +	"SIGUSR1",			// 10
> +	"segfault",			// 11 = SIGSEGV
> +	"SIGUSR2",			// 12
> +	"SIGPIPE",			// 13
> +	"SIGALRM",			// 14
> +	"SIGTERM",			// 15
> +	"SIGSTKFLT",			// 16
> +	"SIGCHLD",			// 17
> +	"SIGCONT",			// 18
> +	"SIGSTOP",			// 19
> +	"SIGTSTP",			// 20
> +	"SIGTTIN",			// 21
> +	"SIGTTOU",			// 22
> +	"SIGURG",			// 23
> +	"SIGXCPU",			// 24
> +	"SIGXFSZ",			// 25
> +	"SIGVTALRM",			// 26
> +	"SIGPROF",			// 27
> +	"SIGWINCH",			// 28
> +	"SIGIO",			// 29 = SIGPOLL = SIGLOST
> +	"SIGPWR",			// 30
> +	"SIGSYS",			// 31 = SIGUNUSED
> +};
> +
>  /*
>   * Trap & Exception support
>   */
> @@ -314,10 +349,10 @@ static void show_signal_msg(int signr, struct  
> pt_regs *regs, int code,
>  	if (!unhandled_signal(current, signr))
>  		return;
>
> -	pr_info("%s[%d]: unhandled signal %d at "REG_FMT \
> -		" nip "REG_FMT" lr "REG_FMT" code %x",
> -		current->comm, current->pid, signr, addr,
> -		regs->nip, regs->link, code);
> +	pr_info("%s[%d]: %s (%d) at "REG_FMT" nip "REG_FMT \
> +		" lr "REG_FMT" code %x",
> +		current->comm, current->pid, signames[signr],
> +		signr, addr, regs->nip, regs->link, code);

Are we sure that signr is always within the limits of the table ?

Christophe
>
>  	print_vma_addr(KERN_CONT " in ", regs->nip);
>
> --
> 2.17.1