linux-kernel - [RFC PATCH 0/2] objtool and cross compilation

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-next>] [day] [month] [year] [list]

Date:   Wed, 30 Sep 2020 11:58:24 +0200
From:   Vasily Gorbik <gor@...ux.ibm.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Miroslav Benes <mbenes@...e.cz>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Julien Thierry <jthierry@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/2] objtool and cross compilation

This is based on v5.9-rc7, before "other architectures support" patches
starting pouring in.

Currently objtool seems to be the only tool from build tools needed
which breaks x86 cross compilation on big endian systems.

But besides x86 cross compilation, endianness awareness is also needed
for big endian architectures objtool support in general.

We have working prototype of objtool support and orc unwinder for s390
made originally by Martin Schwidefsky. I'm trying to bring it in shape
again and refactor to share more code with "generic" part.

But first things first. These 2 patches point to endianness problems
which should be addressed. And I'd be glad to get any ideas how to make
them less ugly.

New "other architectures support" patches currently move only some
problematic parts into x86 arch specific folder. But the main problem
is that arch/x86/lib/insn.c and arch/x86/include/asm/insn.h are shared
across the kernel source and the tools, and there is no common way to
address endianness problems.

Since big endian stuff is only needed for the objtool and not for the
kernel I can try to hide alternative big endian definitions in tools
only header which is included only if __KERNEL__ is not defined. But
that kind of defeats the idea of sharing those files 1 to 1 with tools.

Thoughts? Any suggestions are welcome.

Martin Schwidefsky (1):
  objtool: x86 instruction decoder and big endian cross compiles

Vasily Gorbik (1):
  objtool: fix x86 orc generation on big endian cross compiles

 arch/x86/include/asm/insn.h            | 43 ++++++++++++
 arch/x86/include/asm/orc_types.h       | 24 +++++++
 arch/x86/lib/insn.c                    | 95 +++++++++++---------------
 tools/arch/x86/include/asm/insn.h      | 43 ++++++++++++
 tools/arch/x86/include/asm/orc_types.h | 24 +++++++
 tools/arch/x86/lib/insn.c              | 95 +++++++++++---------------
 tools/objtool/check.c                  |  4 +-
 tools/objtool/elf.c                    | 34 +++++----
 tools/objtool/orc_dump.c               |  4 +-
 tools/objtool/orc_gen.c                |  2 +
 tools/objtool/special.c                |  4 +-
 11 files changed, 243 insertions(+), 129 deletions(-)

-- 
⣿⣿⣿⣿⢋⡀⣀⠹⣿⣿⣿⣿
⣿⣿⣿⣿⠠⣶⡦⠀⣿⣿⣿⣿
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿