linux-kernel - Re: C aggregate passing (Rust kernel policy)

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: <olxh7iwz5yjuuqwpbzgohrl3dkcurbmzij3o2dbha5mtkr2ipn@wtee4jjj7ope>
Date: Wed, 26 Feb 2025 12:41:30 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>, 
	Greg KH <gregkh@...uxfoundation.org>, Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, 
	Ventura Jack <venturajack85@...il.com>, "H. Peter Anvin" <hpa@...or.com>, 
	Alice Ryhl <aliceryhl@...gle.com>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	Gary Guo <gary@...yguo.net>, airlied@...il.com, boqun.feng@...il.com, 
	david.laight.linux@...il.com, hch@...radead.org, ksummit@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, Ralf Jung <post@...fj.de>, 
	Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: C aggregate passing (Rust kernel policy)

On Wed, Feb 26, 2025 at 11:57:26AM -0500, Steven Rostedt wrote:
> 
> [ Adding Josh ]
> 
> On Wed, 26 Feb 2025 11:47:09 -0500
> Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> 
> > On Wed, Feb 26, 2025 at 11:42:41AM -0500, James Bottomley wrote:
> > > On Wed, 2025-02-26 at 11:00 -0500, Steven Rostedt wrote:  
> > > > On Wed, 26 Feb 2025 09:45:53 -0500
> > > > James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > > >   
> > > > > > From some other rust boot system work, I know that the quality of
> > > > > > a    
> > > > > simple backtrace in rust where you just pick out addresses you
> > > > > think you know in the stack and print them as symbols can sometimes
> > > > > be rather misleading, which is why you need an unwinder to tell you
> > > > > exactly what happened.  
> > > > 
> > > > One thing I learned at GNU Cauldron last year is that the kernel
> > > > folks use the term "unwinding" incorrectly. Unwinding to the compiler
> > > > folks mean having full access to all the frames and variables and
> > > > what not for all the previous functions.
> > > > 
> > > > What the kernel calls "unwinding" the compiler folks call "stack
> > > > walking". That's a much easier task than doing an unwinding, and that
> > > > is usually all we need when something crashes.  
> > > 
> > > Well, that's not the whole story.  We do have at least three unwinders
> > > in the code base.  You're right in that we don't care about anything
> > > other than the call trace embedded in the frame, so a lot of unwind
> > > debug information isn't relevant to us and the unwinders ignore it.  In
> > > the old days we just used to use the GUESS unwinder which looks for
> > > addresses inside the text segment in the stack and prints them in
> > > order.  Now we (at least on amd64) use the ORC unwinder because it
> > > gives better traces:
> > > 
> > > https://docs.kernel.org/arch/x86/orc-unwinder.html  
> 
> Note, both myself and Josh (creator of ORC) were arguing with the GCC folks
> until we all figured out we were talking about two different things. Once
> they said "Oh, you mean stack walking. Yeah that can work" and the
> arguments stopped. Lessons learned that day was that compiler folks take
> the term "unwinding" to mean much more than kernel folks, and since we have
> compiler folks on this thread, I'd figure I would point that out.
> 
> We still use the term "unwinder" in the kernel, but during the sframe
> meetings, we need to point out that we all just care about stack walking.
> 
> > 
> > More accurate perhaps, but I still don't see it working reliably - I'm x
> > still having to switch all my test setups (and users) to frame pointers
> > if I want to be able to debug reliably.
> 
> Really? The entire point of ORC was to have accurate stack traces so that
> live kernel patching can work. If there's something incorrect, then please
> report it.

It's been awhile since I've looked at one, I've been just automatically
switching back to frame pointers for awhile, but - I never saw
inaccurate backtraces, just failure to generate a backtrace - if memory
serves.

When things die down a bit more I might be able to switch back and see
if I get something reportable, I'm still in bug crunching mode :)