linux-kernel - Re: objtool warnings in prerelease clang-9

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: <20190702220739.GJ32547@worktop.programming.kicks-ass.net>
Date:   Wed, 3 Jul 2019 00:07:39 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Kees Cook <keescook@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Craig Topper <craig.topper@...el.com>,
        Alexander Potapenko <glider@...gle.com>,
        Bill Wendling <morbo@...gle.com>,
        Stephen Hines <srhines@...gle.com>
Subject: Re: objtool warnings in prerelease clang-9


Hi Nick,

That is good news; and I'll strive to read the email in more detail
in the morning when there is a better chance of me actually
understanding some of it :-)

But his here is something I felt needed clarification:

On Tue, Jul 02, 2019 at 01:53:51PM -0700, Nick Desaulniers wrote:
> Of interest are the disassembled __jump_table entries; in groups of
> three, there is a group for which the second element is duplicated
> with a previous group.  This is bad because (as explained by Peter in
> https://lkml.org/lkml/2019/6/27/118) the triples are in the form (code
> location, jump target, pointer to key).  Duplicate or repeated jump
> targets are unexpected, and will lead to incorrect control flow after
> patching such code locations.

> Also, the jump target should be 0x7 bytes ahead of the location, IIUC.

Even if you mean 'at least' I'm fairly sure this is not correct. The
instruction at the 'code location' is either a jmp.d32 or a nop5 (both 5
bytes). The target must (obviously) be at an instruction boundary, but
really can be anywhere (it is compiler generated after all).