linux-kernel - Re: [PATCH] x86: x86-opcode-map.txt: explain CALLW discrepancy between Intel and AMD

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:	Fri, 13 Feb 2015 13:01:22 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Denys Vlasenko <dvlasenk@...hat.com>
Cc:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Ingo Molnar <mingo@...nel.org>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: x86-opcode-map.txt: explain CALLW discrepancy
 between Intel and AMD

On Thu, Feb 12, 2015 at 08:06:57PM +0100, Denys Vlasenko wrote:
> In 64-bit mode, AMD and Intel CPUs treat 0x66 prefix before branch
> insns differently. For near branches, it affects decode too since
> immediate offset's width is different.
> 
> Signed-off-by: Denys Vlasenko <dvlasenk@...hat.com>
> CC: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
> CC: Ingo Molnar <mingo@...nel.org>
> CC: Oleg Nesterov <oleg@...hat.com>
> CC: linux-kernel@...r.kernel.org
> ---
>  arch/x86/lib/x86-opcode-map.txt | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.txt
> index 1a2be7c..816488c 100644
> --- a/arch/x86/lib/x86-opcode-map.txt
> +++ b/arch/x86/lib/x86-opcode-map.txt
> @@ -273,6 +273,9 @@ dd: ESC
>  de: ESC
>  df: ESC
>  # 0xe0 - 0xef
> +# Note: "forced64" is Intel CPU behavior: they ignore 0x66 prefix
> +# in 64-bit mode. AMD CPUs accept 0x66 prefix, it causes RIP truncation
> +# to 16 bits. In 32-bit mode, 0x66 is accepted by both Intel and AMD.

Well, according to the SDM, Intel truncates too, see the LOOP/LOOPcc
Operation section:

	...
	IF BranchCond = 1
	THEN
	IF OperandSize = 32
	THEN EIP ← EIP + SignExtend(DEST);
	ELSE IF OperandSize = 64
	THEN RIP ← RIP + SignExtend(DEST);
	FI;
	ELSE IF OperandSize = 16
	THEN EIP ← EIP AND 0000FFFFH;		<---

and text talks about 0x67 but that's address size and it is used to size
the rCX register.

So something must be setting the OperandSize and text doesn't mention
anywhere about 0x66 being ignored.

Or have you been doing some empirical experiments? :-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/