linux-kernel - Re: [RFC PATCH v5 17/28] dyndbg: prevent build bugs via -DNO_DYNAMIC_DEBUG

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJfuBxz+vW_aT=ZVM+UgDxDxwph4D+MKB6r518J9vk2YopX+KA@mail.gmail.com>
Date:   Wed, 12 May 2021 12:03:47 -0600
From:   jim.cromie@...il.com
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Bill Wendling <morbo@...gle.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Joerg Roedel <jroedel@...e.de>, Nick Terrell <terrelln@...com>,
        Dave Young <dyoung@...hat.com>,
        Pingfan Liu <kernelfans@...il.com>,
        Atish Patra <atish.patra@....com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:SPARC + UltraSPARC (sparc/sparc64)" 
        <sparclinux@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        kbuild test robot <lkp@...el.com>
Subject: Re: [RFC PATCH v5 17/28] dyndbg: prevent build bugs via -DNO_DYNAMIC_DEBUG_TABLE

On Wed, May 12, 2021 at 8:55 AM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Tue, 11 May 2021 at 20:51, Jim Cromie <jim.cromie@...il.com> wrote:
> >
> > The next patch adds DEFINE_DYNAMIC_DEBUG_TABLE(), which broke several
> > subtrees, including efi, vdso, and some of arch/*/boot/compressed,
> > with various relocation errors, iirc.
> >
> > Avoid those problems by adding a define to suppress the "transparent"
> > DEFINE_DYNAMIC_DEBUG_TABLE() invocation.  I found the x86 problems
> > myself, lkp@...el.com found arm & sparc problems, and may yet find
> > others.
> >
>
> Given that I was only cc'ed on this patch in isolation, would you mind
> adding more clarification here? What is DEFINE_DYNAMIC_DEBUG_TABLE()
> supposed to do, and why is it breaking standalone binaries?
>
>

hi Ard,

the thread starts here:
https://lore.kernel.org/linux-mm/20210511185057.3815777-1-jim.cromie@gmail.com/

the _TABLE macro derives from DEFINE_DYNAMIC_DEBUG_METADATA,
which puts private static struct _ddebug's in section("__dyndbg")
the _TABLE macro populates a different section(".gnu.linkonce.dyndbg"),
which is then placed by linker script at the start of the section.

ISTM that the new section might be whats breaking things.
And maybe that the vmlinux linker script isnt involved.
so the storage the _TABLE wants to define is unbound
(and unused, since there are no pr_debugs)
I did see relocation errors somewhere...

This is my 1st time doing something creative with the linker

As to larger purpose, I'll try to restate the patchset mission:

theres ~45kb savings possible by compressing the highly redundant data (~70kb)
 which decorates pr_debug messages.

1 - split the compressible/decoration columns to a different
section|block, for block compression
      this adds temporary .site pointer from _ddebug -> _ddebug_site

2 -  change code so !site is safe.

_TABLEs only real job is to provide a header record, at the beginning
of the section/array,
for a single .site pointer to the _dyndbg_sites section added in 1.
Because the header has a fixed offset from any pr_debug in the vector,
all pr_debugs can use the headers copy of .site, and dont need their own.
specialize & unionize

So it allows to drop the temporary pointer, restoring memory size
parity with master.
And we then have the _dyndbg_sites  section, full of redundant data,
ready to compress.

suppression with -DNO_DYNAMIC_DEBUG was a workaround, didnt think
about it afterwards

does this clarify ?

thanks
Jim