linux-kernel - Re: Asm & local labels for functions [was: [PATCH v8 05/28] x86/asm: annotate local pseudo-functions]

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: <20190828122417.GH4920@zn.tnic>
Date:   Wed, 28 Aug 2019 14:24:17 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Jiri Slaby <jslaby@...e.cz>
Cc:     tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        x86@...nel.org, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Asm & local labels for functions [was: [PATCH v8 05/28] x86/asm:
 annotate local pseudo-functions]

On Wed, Aug 28, 2019 at 01:47:23PM +0200, Jiri Slaby wrote:
> Let's start with this one: do you really want me to get rid of (local)
> symbols like this? It would make backtraces completely misleading as the
> unwinder would put a name of the previous function (or some garbage,
> depending on unwinder) into the backtrace...

Yes, while looking at your patches, I was thinking about what
would be a good rule to use with which to make symbols local. I
guess those which are small and not really important for stack
traces like "bad_gs" in entry_64., for example. Or "relocated" in
arch/x86/boot/compressed/head_64.S, as another example. That last one
you probably are never going to see in stack traces due to it being too
early anyway.

Or, if we think that those symbols are important for stack traces, then
they should be called something more prominent, with a naming prefix or
so, so that they can be assigned to the respective source easier.

Am I making some sense?

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.