linux-kernel - Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded 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: <20150221024738.GA2899@dhcp-17-102.nay.redhat.com>
Date:	Sat, 21 Feb 2015 10:49:23 +0800
From:	Baoquan He <bhe@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G

On 02/20/15 at 03:53pm, Yinghai Lu wrote:
> On Fri, Feb 20, 2015 at 1:28 AM, Baoquan He <bhe@...hat.com> wrote:
> >
> > Actually kexec is a bootloader which can put kernel at any address. This
> > is done in user space program kexec-tools. However kexec-tools make
> > kernel jump from 64bit into 64bit directly, and has built ident mapping
> > of whole physical memory. I have tried this and it works. kexec is
> > mainly used for kernel developer, kaslr is meaningless for kexec.
> >
> > However kaslr focus on normal kernel, and jump from 32bit to 64bit mode.
> > I can't figure out a way to work around this.
> >
> > Now I just want to figure out what register setting cause GPF when
> > reload kernel above 4G in this jumping from 32bit to 64bit way.
> 
> Then you are not setting  the ident mapping correctly.
> 
> you should make sure add extra ident mapping for the new [output,
> output+output_len - 1].
> bootloader only cover old [output, output+output_len - 1]
> 
> and you should check if the mapping is present before add new one,
> otherwise will overrite
> the one from 64bit bootloader like kexec-tools or grub2-x86_64 etc.
> 
> You could use kernel_ident_mapping_init() from arch/x86/mm/init_64.c
> --- may need to cut and paste or split and include to
> arch/x86/boot/compressed/misc.c
> also you need to find some pages for alloc_pgt_page.

At the beginning I did it just as you said, add IDT table and $PF
handler. Get page fault address and built ident mapping around it when
reload kernel above 4G. In this case 3 more pages are enough if kernel
is put to another 512G and cross the boundary of 512G.
kernel_ident_mapping_init code can be borrowed and need be adjusted a
little bit. This works as expected, but a GPF reported and reboot to
BIOS. That's why I made a simple debug patch as I pasted before to
filter unnecessary interference.

Since in arch/x86/boot/compressed/head_64.S 6 pages are used, 1 for pgd,
1 for pud, 4 for pmd, all of them cover 0~4G ident mapping. So I added 4
more pages as pmd, then 0~8G are covered. Now I hardcoded the output of
randomization of physical address as 5G, means kernel will be reloaded
there and decompressed. With these ident mapping for this hard coded
address should be correctly setted, still that GPF will happen. I
borrowed a printf.c from arch/x86/boot and made it work for
boot/compressed, can see in this case it will decompress successfully
and jump into arch/x86/kernel/head_64.S, then it reboot there during a
jump.

> 
> Thanks
> 
> Yinghai
--
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/