From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755331AbbBBJgu (ORCPT ); Mon, 2 Feb 2015 04:36:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50356 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753132AbbBBJgp (ORCPT ); Mon, 2 Feb 2015 04:36:45 -0500 Date: Mon, 2 Feb 2015 17:34:30 +0800 From: Baoquan He To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , X86 ML , Kees Cook , Vivek Goyal , Thomas Deutschmann Subject: Re: [PATCH 0/6] randomize kernel physical address and virtual address separately Message-ID: <20150202093430.GA25032@dhcp-16-105.nay.redhat.com> References: <1421811437-2787-1-git-send-email-bhe@redhat.com> <54BF28D8.70107@amacapital.net> <20150201081028.GA1573@dhcp-17-102.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/01/15 at 05:13am, Andy Lutomirski wrote: > On Sun, Feb 1, 2015 at 12:10 AM, Baoquan He wrote: > > On 01/20/15 at 08:19pm, Andy Lutomirski wrote: > >> On 01/20/2015 07:37 PM, Baoquan He wrote: > >> > >> I have no idea what the #PF thing you're referring to is, but I have > >> code to implement a #PF handler in boot/compressed if it would be > >> helpful. It's two patches: > >> > >> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=sync_rand_seed&id=89476ea6a2becbaee4f45c3b6689ff31b6aa959a > >> > >> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=sync_rand_seed&id=142d86921e6f271261584016fc8cfa5cdbf455ba > >> > >> You can't recover from a page fault in my version of this code, but that > >> would be straightforward to add. > >> > > Hi all, > > > > I used Andy's patch to setup idt and implement #PF handler before kernel > > decompression, and it works. Then a problem is encountered that when > > choose a position above 4G and decompress kernel there system will > > reboot to BIOS after kernel decompression. I use hlt command to position > > where the asm code will cause that reboot and found it happened after > > jumping when adjusted page table is loaded in arch/x86/kernel/head_64.S > > I applied this to Linus' tree today, and I get: > > early console in decompress_kernel > KASLR disabled by default... > > Decompressing Linux... > > XZ-compressed data is corrupt > > -- System halted > > If I comment out the output = 0x140000000 line, then it boots. > > With gzip instead of XZ, it just gets stuck at Decompressing Linux... > > Presumably this is because 0x140000000 is an invalid address in my VM. > I added more RAM, and I get a nice reboot loop. QEMU thinks that it's > a page fault causing a triple fault. Thanks a lot for help, Andy. Currently in boot/compressed/head_64.S, 6 page tables are used to build the identity mapping in 0~4G area, 1 page used for pgd table, 1 page used for pud table, and left 4 pgaes used for pmd table. So I added 4 more pages for pmd table, then it cover 0~8G area. So during kernel decompressing, if trying to reload kernel to be above 4G, physical memory have to be larger than 4G. So you can set output=0x100000000, then you only need 4.5G memory. Then if you add below 2 lines of code, you will see the output messgae from screen : "Booting the kernel." diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index a468c0a..1c039a5 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -181,6 +181,10 @@ ENTRY(secondary_startup_64) movl $(X86_CR4_PAE | X86_CR4_PGE), %ecx movq %rcx, %cr4 +/*This is used to position where the kernel will reboot to bios*/ +1: hlt + jmp 1b + /* Setup early boot stage 4 level pagetables. */ addq phys_base(%rip), %rax movq %rax, %cr3 > > If I add in my IDT code and #PF handler, nothing changes. If I > re-enable relocations, I get: > > 32-bit relocation outside of kernel! Here is a code bug which is fixed by my posted patch 2/6: a bug that relocation can not be handled when kernel is loaded above 2G So now I use the debug patch in last mail to debug how to make kernel move to above 4G position and be decompressed there. So I just the comment out the handle_relocations() calling. Actually the debug patch can filter unncecessary interference. > > Can you post the whole set of patches you're using or a link to a git tree? I am creating a repo on git hub and push my patchset, then it can be got publicly. Will send it as soon as it's finished. Btw, I didn't try xz, just always bzImage. Thanks Baoquan