linux-kernel - Re: [PATCH v7 00/27] x86, boot, 64bit: Add support for loading ramdisk and bzImage above 4G

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: <171018c8-b640-4234-a25e-7040d9e21acd@email.android.com>
Date:	Sun, 23 Dec 2012 20:54:37 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <bp@...en8.de>, Yinghai Lu <yinghai@...nel.org>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 00/27] x86, boot, 64bit: Add support for loading ramdisk and bzImage above 4G

Makes sense.  Ljmpq it is.  A comment might be useful.

Borislav Petkov <bp@...en8.de> wrote:

>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 <hpa@...or.com>
>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)
>> 
>>  #ifdef CONFIG_HOTPLUG_CPU
>>  /*
>> 
>> 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.
>
>HTH.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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/