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:   Wed, 16 Feb 2022 14:13:24 -0800
From:   Josh Poimboeuf <>
To:     Joe Lawrence <>
Cc:     Alexander Lobakin <>,
        Fāng-ruì Sòng <>,,,
        Borislav Petkov <>,
        Jesse Brandeburg <>,
        Kristen Carlson Accardi <>,
        Kees Cook <>,
        Miklos Szeredi <>,
        Ard Biesheuvel <>,
        Tony Luck <>,
        Bruce Schlobohm <>,
        Jessica Yu <>,
        kernel test robot <>,
        Miroslav Benes <>,
        Evgenii Shatokhin <>,
        Jonathan Corbet <>,
        Masahiro Yamada <>,
        Michal Marek <>,
        Nick Desaulniers <>,
        Herbert Xu <>,
        "David S. Miller" <>,
        Thomas Gleixner <>,
        Will Deacon <>, Ingo Molnar <>,
        Christoph Hellwig <>,
        Dave Hansen <>,
        "H. Peter Anvin" <>,
        Andy Lutomirski <>,
        Peter Zijlstra <>,
        Arnd Bergmann <>,
        Nathan Chancellor <>,
        Masami Hiramatsu <>,
        Marios Pomonis <>,
        Sami Tolvanen <>,
        "H.J. Lu" <>, Nicolas Pitre <>,,,,,
Subject: Re: [PATCH v10 02/15] livepatch: avoid position-based search if `-z
 unique-symbol` is available

On Wed, Feb 16, 2022 at 03:32:41PM -0500, Joe Lawrence wrote:
> > Right, so we'd have to abandon position-based search in favor of
> > file+func based search.
> > 
> > It's not perfect because there are still a few file+func duplicates.
> > But it might be good enough.  We would presumably just refuse to patch a
> > duplicate.  Or we could remove them (and enforce their continued removal
> > with tooling-based warnings).
> > 
> You're talking about duplicate file+func combinations as stored in the
> symbol table?


> ...
>       6 OBJECT core.c::__func__.3
>       6 OBJECT core.c::__func__.5
>       7 OBJECT core.c::__func__.1
>       8 OBJECT core.c::__func__.0
>       8 OBJECT core.c::__func__.2
> We could probably minimize the FUNC duplicates with unique names, but
> I'm not as optimistic about the OBJECTs as most are created via macros
> like __already_done.X.  Unless clever macro magic?

Good point about objects, as we rely on disambiguating them for klp
relocations.  Luckily, the fact that most of them are created by macros
is largely a good thing.  We consider most of those to be "special"
static locals, which don't actually need to be correlated or referenced
with a klp reloc.

For example:

- '__func__' is just the function name.  The patched function shouldn't
  need to reference the original function's function name string.

- '__already_done' is used for printk_once(); no harm in making a new
  variable initialized to false and printing it again; or converting
  printk_once() to just printk() to avoid an extra print.

- '__key' is used by lockdep to track lock usage and validate locking
  order.  It probably makes sense to use a new key in the patched
  function, since the new function might have different locking

> Next question: what are the odds that these entries, at least the ones
> we can't easily rename, need disambiguity for livepatching?  or
> kpatch-build for related purposes?

I would guess the odds are rather low, given the fact that there are so
few functions, and we don't care about most of the objects on the list.

If duplicates were to become problematic then we could consider adding
tooling which warns on a duplicate file:sym pair with the goal of
eliminating duplicates (exculding the "special" objects).


Powered by blists - more mailing lists