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  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:   Tue, 12 Jan 2021 21:01:54 +0000
From:   Mark Brown <>
To:     Nick Desaulniers <>
Cc:     Andy Lutomirski <>,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        Fangrui Song <>,
        Arnd Bergmann <>,
        Josh Poimboeuf <>,
        Jonathan Corbet <>,,
        "H. Peter Anvin" <>,
        Nathan Chancellor <>,
        Miguel Ojeda <>,
        Jiri Slaby <>,
        Joe Perches <>,,,
Subject: Re: [PATCH v4] x86/entry: emit a symbol for register restoring thunk

On Tue, Jan 12, 2021 at 11:46:24AM -0800, Nick Desaulniers wrote:


> when building with LLVM_IAS=1 (Clang's integrated assembler). Josh
> notes:

>   So basically, you can use an .L symbol *inside* a function or a code
>   segment, you just can't use the .L symbol to contain the code using a
>   SYM_*_START/END annotation pair.

is a stronger statement than this:

> +  Developers should avoid using local symbol names that are prefixed with
> +  ``.L``, as this has special meaning for the assembler; a symbol entry will
> +  not be emitted into the symbol table. This can prevent ``objtool`` from
> +  generating correct unwind info. Symbols with STB_LOCAL binding may still be
> +  used, and ``.L`` prefixed local symbol names are still generally useable
> +  within a function, but ``.L`` prefixed local symbol names should not be used
> +  to denote the beginning or end of code regions via

and seems more what I'd expect - SYM_FUNC* is also affected for example.
Even though other usages are probably not very likely it seems better to
keep the stronger statement in case someone comes up with one, and to
stop anyone spending time wondering why only SYM_CODE_START_LOCAL is

This also looks like a good candiate for a checkpatch rule, but that can
be done separately of course.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists