linux-kernel - Re: [External] Re: [PATCH] riscv/fault: Dump user opcode bytes on fatal faults

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: <747a3382-17e7-4167-a1bb-30a9482be4d1@spud>
Date:   Wed, 29 Mar 2023 07:24:45 +0100
From:   Conor Dooley <conor.dooley@...rochip.com>
To:     运辉崔 <cuiyunhui@...edance.com>
CC:     Conor Dooley <conor@...nel.org>, <paul.walmsley@...ive.com>,
        <palmer@...belt.com>, <aou@...s.berkeley.edu>,
        <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [External] Re: [PATCH] riscv/fault: Dump user opcode bytes on
 fatal faults

Hey 运辉崔,

On Wed, Mar 29, 2023 at 11:52:21AM +0800, 运辉崔 wrote:
> On Wed, Mar 29, 2023 at 1:03 AM Conor Dooley <conor@...nel.org> wrote:
> 
> > riscv/fault: Dump user opcode bytes on fatal faults
> >
> > I think you can drop the /fault, we don't usually use prefixes that like
> > for RISC-V.
> >
> ok, i'll update it on v2
> 
> 
> > > In this way, we found the problem: in the system bringup , it is
> > > precisely that we have not enabled the floating point function.
> >
> > What do you mean by that "have not enabled the floating point function"?
> 
> The related cpu feature(COMPAT_HWCAP_ISA_F) is not enabled in the
> riscv_fill_hwcap function interface.

Right, I'm trying to figure out of this is another bug in the kernel -
if you don't have "fd" in riscv,isa in your devicetree then, even if
CONFIG_FPU is set, none of the FPU code is meant to run, right?

> > > So when an exception occurs, it is necessary to dump the instruction
> > > that caused the exception, like x86/fault (ba54d856a9d8).
> >
> > That's not the usual format for referring to commits, checkpatch should
> > complain about that.
> 
> ok, i'll update it on v2.
> 
> > >
> > > Logs:
> > > [    0.822481] Run /init as init process
> > > [    0.837569] init[1]: unhandled signal 4 code 0x1 at 0x000000000005e028 in bb[10000+5fe000]
> > > [    0.932292] CPU: 0 PID: 1 Comm: init Not tainted 5.14.0-rc4-00048-g4a843c9043e8-dirty #138
> >
> > 5.14-rc4?, oof! Need to get yourself onto a released, LTS kernel I
> > think!
> 
> Just a print,v6.3-rc1 also has this problem.

Right, but that's a pretty old kernel to be using!
Seeing 5.14 and the patch not applying made me wonder if the patch was
generated against an old kernel.

> > Anyway, this patch doesn't apply to either riscv/for-next, riscv/fixes
> > or v6.3-rc1. What is the appropriate base to apply this patch?
> 
> ok, i'll update it on v2.
> 
> 
> > > [    0.936073]  s2 : 0000000000000000 s3 : 0000000000000000 s4 : 0000000000000000
> > > [    0.936495]  s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
> > > [    0.936947]  s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
> > > [    0.937487]  s11: 0000000000d14980 t3 : 0000000000000000 t4 : 0000000000000000
> > > [    0.937954]  t5 : 0000000000000000 t6 : 0000000000000000
> > > [    0.938510] status: 0000000200000020 badaddr: 00000000f0028053 cause: 0000000000000002
> >
> > I have no idea what the significance of this particular backtrace is,
> > could you elaborate on what this is demonstrating? (and drop the leading
> > [###] too as it doesn't exactly add anything!
> 
> The current call trace does not show the instruction that caused the
> exception. ok, I'll remove it on v2.

What would be nice to have is what the new show_opcodes() function will
look like ;)

Thanks,
Conor.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)