On Feb 19, 2025, at 11:52 AM, Kees Cook <kees@xxxxxxxxxx> wrote > Is anyone able to test this patch? And Brian will setting a sysctl be > okay for your use-case? Hi Kees, I've verified that the sysctl tunable works as expected. readelf is showing that the VMAs are unsorted by default, with the tunable set to 0. When the tunable is set to 1, the VMAs are sorted. I also verified that the backtrace for unsorted and sorted cores are viewable in GDB. The backtrace reported by eu-stack shows up fine in the unsorted case, when attempting to reproduce with Michael's steps. As expected, I see the same error as Michael in the sorted case, when reproducing with his steps. Interestingly enough, in the sorted case, I found that if the crashing program is not linked statically, eu-stack will work fine. However, if the crashing program is linked statically, eu-stack will throw an error, as reported. Anyway, this patch looks pretty good. > > diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst > index a43b78b4b646..35d5d86cff69 100644 > --- a/Documentation/admin-guide/sysctl/kernel.rst > +++ b/Documentation/admin-guide/sysctl/kernel.rst > @@ -222,6 +222,17 @@ and ``core_uses_pid`` is set, then .PID will be appended to > the filename. > > > +core_sort_vma > +============= > + > +The default coredump writes VMAs in address order. By setting > +``core_sort_vma`` to 1, VMAs will be written from smallest size > +to largest size. This is known to break at least elfutils, but > +can be handy when dealing with very large (and truncated) > +coredumps where the more useful debugging details are included > +in the smaller VMAs. > + > + Just one comment here, this should go up one entry to maintain alphabetical ordering. Thanks, Brian
