linux-kernel - Re: [PATCH] riscv: eliminate unreliable __builtin_frame

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]

Date:   Wed, 19 Jan 2022 16:15:07 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     schwab@...ux-m68k.org
CC:     jrtc27@...c27.com, changbin.du@...il.com,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject:     Re: [PATCH] riscv: eliminate unreliable __builtin_frame_address(1)

On Wed, 19 Jan 2022 15:53:07 PST (-0800), schwab@...ux-m68k.org wrote:
> On Jan 19 2022, Jessica Clarke wrote:
>
>> What’s your point?
>
> LLVM doesn't have to deal with the extra complexity.
>
>> doesn’t mean other toolchains that do need that to be correct should
>> just do something wrong.
>
> __builtin_frame_address with count > 0 is considered bad.  Nobody should
> use it.

The documentation is very clear about this.

I don't really see anything to argue about here: our code violates the 
spec and is producing results we don't like, though the spec allows for 
much worse.  We shouldn't have had that code in the first place, but it 
slipped through as these things sometimes do.  This is just a regular 
old bug that deserves to be fixed.  Just because one compiler produces 
answers we like doesn't mean it's valid code, that's the whole point of 
having a spec in the first place.

> You don't have to be arrogant.

This has been a persistent problem, it's really just not productive.  
We're still trying to dig out from the last two rounds of silliness, 
let's not have another one.

I don't see anything wrong with the patch in question, but these "stack 
trace without debug info" things are always tricky and thus warrant a 
proper look.  I'm in the middle of juggling some patches right now, I'll 
try to take a look but it's fairly far down the queue.

Always happy to have help looking these things over, let's try to keep 
things constructive, though.  We've already got enough work to do.