linux-kernel - Re: [RFC[ Alloc in vsprintf

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:   Sun, 26 Jun 2022 16:51:58 -0400
From:   Kent Overstreet <kent.overstreet@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Laight <David.Laight@...lab.com>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Matthew Wilcox <willy@...radead.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>
Subject: Re: [RFC[ Alloc in vsprintf

On Sun, Jun 26, 2022 at 01:39:01PM -0700, Joe Perches wrote:
> On Sun, 2022-06-26 at 13:19 -0700, Linus Torvalds wrote:
> > On Sun, Jun 26, 2022 at 12:53 PM Joe Perches <joe@...ches.com> wrote:
> > > 
> > > In a reply to the printbufs thread, I wrote a proposal to use an
> > > alloc to reduce stack in vsprintf when CONFIG_KALLSYMS is enabled.
> > > 
> > > No one has replied to this but I think it's somewhat sensible.
> > 
> > I think that's a bad idea.
> 
> Somewhat sensible not sensible...
> 
> > Those things are *literally* called from panic situations, which may
> > be while holding core memory allocation locks, or similar.
> 
> True, and special_hex_number was used on alloc failure.
> 
> > Now, you are correct that the stack buffer is annoying. But I think
> > the proper way to fix that is to say "we already *have* the target
> > buffer, let's use it".
> 
> OK, and that's true for all the temp stack buffers in every %p<foo>.

Serious question: why are you trying to half-ass just _one_ of these functions
when I've been working on solving stack allocations in all of them? I've already
killed every single stack buffer in the last patch series that was posted except
for symbol_string(). I would welcome the help if you wanted to tackle that one.

It's not completely trivial because while kallsyms_expand_symbol() can be
trivially converted to printbufs - it just outputs one char at a time, so that
becomes prt_char() - it's not a output-once-and-done algorithm:
cleanup_symbol_name() then goes back over the output buffer and modifies it in
place (ew), because of weird clang things that it's got #ifdefs for.

Specifically, it's truncating the output at the first period (easy to convert;
just stop when we see a period) but then it truncates at the last $ - why? do we
have symbols when building with gcc that legitimately have dollar signs in them?
One would hope we could drop the #ifdefs but that needs to be checked.

That's as far as I got looking at it just now. It will be some time before I
have time to do it properly and run tests and research what I'm doing (because
I am completely buried in bcachefs bugs to work through at the moment, and
getting sucked into working on test automation _again_ when I have a million
more valuable things I could be working on because the test infrastructure story
for the kernel is still a shitshow, but that's another rant).

Anayways, I'm trying to take the time to do this stuff right, but there's a
_lot_ of work involved, so if you want to help out instead of just slag what I'm
doing... well, it'd be nice...

Cheers,
Kent