linux-kernel - Re: [tip: objtool/core] x86/insn: Support big endian cross-compiles

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]

Date:   Mon, 12 Oct 2020 09:02:28 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Vasily Gorbik <gor@...ux.ibm.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        x86 <x86@...nel.org>
Subject: Re: [tip: objtool/core] x86/insn: Support big endian cross-compiles

On Sat, 10 Oct 2020 16:02:10 +0200
Vasily Gorbik <gor@...ux.ibm.com> wrote:

> On Fri, Oct 09, 2020 at 10:49:21PM +0200, Borislav Petkov wrote:
> > On Fri, Oct 09, 2020 at 10:38:22PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 07, 2020 at 04:20:19PM -0000, tip-bot2 for Martin Schwidefsky wrote:
> > > > The following commit has been merged into the objtool/core branch of tip:
> > > > 
> > > > Commit-ID:     2a522b53c47051d3bf98748418f4f8e5f20d2c04
> > > > Gitweb:        https://git.kernel.org/tip/2a522b53c47051d3bf98748418f4f8e5f20d2c04
> > > > 
> > > > x86/insn: Support big endian cross-compiles
> > > 
> > > This commit breaks the x86 build with CONFIG_X86_DECODER_SELFTEST=y.
> > > 
> > > I've asked Boris to truncate tip/objtool/core.
> > 
> > Yeah, top 4 are gone until this is resolved.
> > 
> > What I would suggest is to have a look at how tools/ headers are kept
> > separate from kernel proper ones, see tools/include/ and how those
> > headers there are full of dummy definitions just so it builds.
> > 
> > And then including a global one like linux/kernel.h is just looking for
> > trouble:
> > 
> > In file included from ./include/uapi/linux/byteorder/little_endian.h:12,
> >                  from ./include/linux/byteorder/little_endian.h:5,
> >                  from /usr/include/x86_64-linux-gnu/asm/byteorder.h:5,
> >                  from ./arch/x86/include/asm/insn.h:10,
> >                  from arch/x86/tools/insn_sanity.c:21:
> > ./tools/include/linux/types.h:30:18: error: conflicting types for ‘u64’
> >    30 | typedef uint64_t u64;
> 
> Sigh... I have not realized there are more usages of insn.c which are
> conditionally compiled. It's not like you grep *.c files to find who
> includes them regularity.

Yes, x86 insn library code is used for the sanity check tool too.

> 
> Looks like there is no way to find common byte swapping helpers for
> the kernel and tools then. Even though tools provide quite a bunch of
> them in tools/include/. So, completely avoiding mixing "kernel" and
> "userspace" headers would look like the following (delta to commit
> mentioned above):
> ---
> 
> diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
> index 004e27bdf121..68197fe18a11 100644
> --- a/arch/x86/include/asm/insn.h
> +++ b/arch/x86/include/asm/insn.h
> @@ -7,7 +7,13 @@
>   * Copyright (C) IBM Corporation, 2009
>   */
>  
> +#ifdef __KERNEL__
>  #include <asm/byteorder.h>
> +#define insn_cpu_to_le32 cpu_to_le32
> +#else
> +#include <endian.h>
> +#define insn_cpu_to_le32 htole32
> +#endif
>  /* insn_attr_t is defined in inat.h */
>  #include <asm/inat.h>
>  
> @@ -47,7 +53,7 @@ static inline void insn_field_set(struct insn_field *p, insn_value_t v,
>  				  unsigned char n)
>  {
>  	p->value = v;
> -	p->little = __cpu_to_le32(v);
> +	p->little = insn_cpu_to_le32(v);
>  	p->nbytes = n;
>  }
>  
> diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
> index 520b31fc1f1a..003f32ff7798 100644
> --- a/arch/x86/lib/insn.c
> +++ b/arch/x86/lib/insn.c
> @@ -5,7 +5,6 @@
>   * Copyright (C) IBM Corporation, 2002, 2004, 2009
>   */
>  
> -#include <linux/kernel.h>
>  #ifdef __KERNEL__
>  #include <linux/string.h>
>  #else
> @@ -16,15 +15,23 @@
>  
>  #include <asm/emulate_prefix.h>
>  
> +#ifdef __KERNEL__
> +#define insn_le32_to_cpu le32_to_cpu
> +#define insn_le16_to_cpu le16_to_cpu
> +#else
> +#define insn_le32_to_cpu le32toh
> +#define insn_le16_to_cpu le16toh
> +#endif
> +
>  #define leXX_to_cpu(t, r)						\
>  ({									\
>  	__typeof__(t) v;						\
>  	switch (sizeof(t)) {						\
> -	case 4: v = le32_to_cpu(r); break;				\
> -	case 2: v = le16_to_cpu(r); break;				\
> +	case 4: v = insn_le32_to_cpu(r); break;				\
> +	case 2: v = insn_le16_to_cpu(r); break;				\
>  	case 1:	v = r; break;						\
> -	default:							\
> -		BUILD_BUG(); break;					\
> +	default: /* relying on -Wuninitialized to report this */	\
> +		break;							\
>  	}								\
>  	v;								\
>  })
> --
> And the same for the tools/*
> No linux/kernel.h means no BUILD_BUG(), but -Wuninitialized actually
> does a decent job in this case:
> arch/x86/../../../arch/x86/lib/insn.c:605:37: error: variable 'v' is
> 		uninitialized when used here [-Werror,-Wuninitialized]
>                 insn_field_set(&insn->immediate2, get_next(long, insn), 1);
>                                                   ^~~~~~~~~~~~~~~~~~~~

Can you initialize v with 0 ? Anyway it will be optimized out while
compiling the code.

> 
> Masami, Josh,
> would that be acceptable?

Yes.

Thank you,


-- 
Masami Hiramatsu <mhiramat@...nel.org>