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, 14 Jul 2021 15:48:53 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        "open list\:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Geoffrey Thomas <geofft@...reload.com>,
        Finn Behrens <me@...enk.de>,
        Adam Bratschi-Kaye <ark.email@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>
Subject: Re: [PATCH 02/17] kallsyms: increase maximum kernel symbol length to 512

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Wed, Jul 14, 2021 at 1:09 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
>> Are you thinking the hashed kernel symbols need to have their types
>> included in the hash?
>
> I think the hash should be the whole mangled name. So yes, for Rust
> symbols they'd have the the type information.

Sorry I was meaning to ask should the C symbols that get hashed
include their types in the hash as well?  Because if everything
is going to be hashed we need to clear definition of what we do
with good old C symbols as well.

>>  Or is this just a hash to make the names a managable size?
>
> No, if that was the only point of it, the "just use two bytes for
> length" would be simpler.
>
> But I don't think we want to do run-time de-mangling of names in the
> kernel when doing stack traces, which implies that the kallsym
> information in the kernel should be the de-mangled names.
>
> That makes the names nice and readable, and also makes this "maximum
> symbol length" thing a non-issue.
>
> BUT.
>
> It also means that you can't use those names for linking purposes, so
> you'd then need to have a "full version" for that. But as Willy
> pointed out elsewhere, you might as well just use a constant-sized
> hash for that, rather than have both a manged and a de-mangled name.

Just to clarify.  We want this for the C symbols as well?

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ