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  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:	Sun, 23 Dec 2012 19:45:16 +0100
From:	Borislav Petkov <>
To:	Yinghai Lu <>
Cc:	"H. Peter Anvin" <>,
	Konrad Rzeszutek Wilk <>,
	Thomas Gleixner <>,
	Ingo Molnar <>,
	"Eric W. Biederman" <>,
	Andrew Morton <>,
Subject: Re: [PATCH v7 00/27] x86, boot, 64bit: Add support for loading
 ramdisk and bzImage above 4G

On Sun, Dec 23, 2012 at 10:00:26AM -0800, Yinghai Lu wrote:
> On Sun, Dec 23, 2012 at 6:33 AM, H. Peter Anvin <> wrote:
> > Explanation please?
> you have following change in the patch
>         /* Finally jump to run C code and to be on real kernel address
>          * Since we are running on identity-mapped space we have to jump
>          * to the full 64bit address, this is only possible as indirect
>          * jump.  In addition we need to ensure %cs is set so we make this
> -        * a far return.
> +        * a far jump.
>          */
> -       movq    initial_code(%rip),%rax
>         pushq   $0              # fake return address to stop unwinder
> -       pushq   $__KERNEL_CS    # set correct cs
> -       pushq   %rax            # target address in negative space
> -       lretq
> +       /* gas 2.22 is buggy and mis-assembles ljmpq */
> +       rex64 ljmp *initial_code(%rip)
>  /*
> remove that change, AMD systems works again.

Right, the original code did a RET FAR by popping CS and rIP from the
stack. And we did prepare the stack properly before that so it worked.

Now, the ljmp translates to a JMP FAR:

ffffffff8100016e:       48 ff 2d ab a5 7f 00    rex.W ljmpq *0x7fa5ab(%rip)        # ffffffff817fa720 <initial_code>
ffffffff81000175:       66 66 2e 0f 1f 84 00    data32 nopw %cs:0x0(%rax,%rax,1)
ffffffff8100017c:       00 00 00 00 

and in 64-bit mode it has for an operand a 16-bit selector followed by a
32-bit offset.

Now, Intel SDM says also this:

REX.W + FF /5 JMP m16:64 A Valid N.E. Jump far, absolute indirect,
address given in m16:64.

And I don't think AMD supports a 64-bit offset. At least I don't see it
in the APM where it has only:

JMP FAR mem16:16 FF /5 Far jump indirect, with the target specified by a far
                      pointer in memory.
JMP FAR mem16:32 FF /5 Far jump indirect, with the target specified by a far
pointer in memory.

This is at least what I can see at a quick scan. I could ask around if
AMD actually supports that FF /5 with a REX.W prefix and it is not only
a documentation omission.



Sent from a fat crate under my desk. Formatting is fine.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists