On 4/9/21 5:53 PM, Josh Poimboeuf wrote: > On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote: >> On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote: >>>> FWIW, over the years we've had zero issues with encoding the frame >>>> pointer on x86. After you save pt_regs, you encode the frame pointer to >>>> point to it. Ideally in the same macro so it's hard to overlook. >>>> >>> >>> I had the same opinion. In fact, in my encoding scheme, I have additional >>> checks to make absolutely sure that it is a true encoding and not stack >>> corruption. The chances of all of those values accidentally matching are, >>> well, null. >> >> Right, stack corruption -- which is already exceedingly rare -- would >> have to be combined with a miracle or two in order to come out of the >> whole thing marked as 'reliable' :-) >> >> And really, we already take a similar risk today by "trusting" the frame >> pointer value on the stack to a certain extent. > > Oh yeah, I forgot to mention some more benefits of encoding the frame > pointer (or marking pt_regs in some other way): > > a) Stack addresses can be printed properly: '%pS' for printing regs->pc > and '%pB' for printing call returns. > > Using '%pS' for call returns (as arm64 seems to do today) will result > in printing the wrong function when you have tail calls to noreturn > functions on the stack (which is actually quite common for calls to > panic(), die(), etc). > > More details: > > https://lkml.kernel.org/r/20210403155948.ubbgtwmlsdyar7yp@treble > > b) Stack dumps to the console can dump the exception registers they find > along the way. This is actually quite nice for debugging. > > Great. I am preparing version 3 taking into account comments from yourself, Mark Rutland and Mark Brown. Stay tuned. Madhavan
