linux-kernel - Re: [PATCH 0/6] randomize kernel physical address and virtual address separately

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:	Sun, 1 Feb 2015 16:10:28 +0800
From:	Baoquan He <bhe@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	linux-kernel@...r.kernel.org, hpa@...or.com, tglx@...utronix.de,
	mingo@...hat.com, x86@...nel.org, keescook@...omium.org,
	vgoyal@...hat.com, whissi@...ssi.de
Subject: Re: [PATCH 0/6] randomize kernel physical address and virtual
 address separately

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

        /* Setup early boot stage 4 level pagetables. */
        addq    phys_base(%rip), %rax   
        movq    %rax, %cr3     
    
        /* Ensure I am executing from virtual addresses */
        movq    $1f, %rax      
        jmp     *%rax          
1:  
    
        /* Check if nx is implemented */
        movl    $0x80000001, %eax       
        cpuid                                                                                                                                    
        movl    %edx,%edi

Now I doubt gdt table is not approporiate when extend identity mapping
to be above 4G in arch/x86/boot/compressed/head_64.S. As far as I
understand, that gdt is a gdt with the 64bit segments using 32bit
descriptor, still has attribute of segment base addr and limit. I wrote
a simple patch to debug this, but still don't know how to make it work,
does anyone can help or point out what I should do to make it work?


>From 40a550ad94ca5927586fb85d3419200dbea9ebd8 Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@...hat.com>
Date: Sun, 1 Feb 2015 07:42:09 +0800
Subject: [PATCH] extend the identity mapping to 8G
This patch add 4 more pages as pmd directory tables to extend the
identity mapping to cover 8G. And hardcode the position to 5G where
kernel will be relocated and decompressed. Meanwhile commented out
the relocation handling calling.

Signed-off-by: Baoquan He <bhe@...hat.com>
---
 arch/x86/boot/compressed/head_64.S | 8 ++++----
 arch/x86/boot/compressed/misc.c    | 3 +++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index 6b1766c..74da678 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -123,7 +123,7 @@ ENTRY(startup_32)
 	/* Initialize Page tables to 0 */
 	leal	pgtable(%ebx), %edi
 	xorl	%eax, %eax
-	movl	$((4096*6)/4), %ecx
+	movl	$((4096*10)/4), %ecx
 	rep	stosl
 
 	/* Build Level 4 */
@@ -134,7 +134,7 @@ ENTRY(startup_32)
 	/* Build Level 3 */
 	leal	pgtable + 0x1000(%ebx), %edi
 	leal	0x1007(%edi), %eax
-	movl	$4, %ecx
+	movl	$8, %ecx
 1:	movl	%eax, 0x00(%edi)
 	addl	$0x00001000, %eax
 	addl	$8, %edi
@@ -144,7 +144,7 @@ ENTRY(startup_32)
 	/* Build Level 2 */
 	leal	pgtable + 0x2000(%ebx), %edi
 	movl	$0x00000183, %eax
-	movl	$2048, %ecx
+	movl	$4096, %ecx
 1:	movl	%eax, 0(%edi)
 	addl	$0x00200000, %eax
 	addl	$8, %edi
@@ -476,4 +476,4 @@ boot_stack_end:
 	.section ".pgtable","a",@nobits
 	.balign 4096
 pgtable:
-	.fill 6*4096, 1, 0
+	.fill 10*4096, 1, 0
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index a950864..47c8c80 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -404,6 +404,7 @@ asmlinkage __visible void *decompress_kernel(void *rmode, memptr heap,
 	output = choose_kernel_location(input_data, input_len, output,
 					output_len > run_size ? output_len
 							      : run_size);
+	output = 0x140000000;
 
 	/* Validate memory location choices. */
 	if ((unsigned long)output & (MIN_KERNEL_ALIGN - 1))
@@ -427,8 +428,10 @@ asmlinkage __visible void *decompress_kernel(void *rmode, memptr heap,
 	 * 32-bit always performs relocations. 64-bit relocations are only
 	 * needed if kASLR has chosen a different load address.
 	 */
+#if 0
 	if (!IS_ENABLED(CONFIG_X86_64) || output != output_orig)
 		handle_relocations(output, output_len);
+#endif
 	debug_putstr("done.\nBooting the kernel.\n");
 	return output;
 }
-- 
1.9.3



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