linux-kernel - Re: [PATCH v2 7/9] get the random phy addr according to slot

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:	Wed, 4 Mar 2015 20:08:56 +0800
From:	Baoquan He <bhe@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Kees Cook <keescook@...omium.org>,
	Vivek Goyal <vgoyal@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 7/9] get the random phy addr according to slot_area
 info

On 03/03/15 at 08:14am, Yinghai Lu wrote:
> On Tue, Mar 3, 2015 at 3:42 AM, Baoquan He <bhe@...hat.com> wrote:
> >
> > Here input means the region where kernel was linked to load?
> >
> > In normal kernel the linked address is 0x1000000. In your input region
> > the result of ALIGN(0x13f5ed3b4, CONFIG_PHYSICAL_ALIGN) is 0x140000000.
> > And size of this region is smaller than 16M. It should return in
> > process_e820_entry() with two checks.
> >
> > I guess you use kexec or a special bootloader to put kernel in this
> > load address.
> >
> 
> 
Hi Yinghai,

I checked code but didnt' find the code bug. Now I plan to hardcode your
data to the avoid[] array, then test on my laptop. Then I can check what
happened by message printing. Coudl you please help clarify the datas I
wrote below?

> with patched grub2 that load kernel/initrd/param/cmdline etc above 4G.
> 

Here,

avoid[0]
input = 0x13f376000;
input_size = 9.55M since its region is [0x13f376000-0x13f37dfff]

addr = 0x13f37dfff - 0x338d000 = 0x13bff0fff
size = (0x338d000 >> 12) + 32768 + 18 = 45983 = 0xb39f


avoid[1]
initrd [0x13f376000-0x13f37dfff]
addr = 0x13f376000
size = 0x8000


avoid[2]
cmdline [13fffb000,13fffb7fe]
addr = 0x13fffb000
size =  0x13fffb7fe - 0x13fffb000 = 0x7ff

avoid[3]
heap: [0x13f376000-0x13f37dfff]
addr = 0x13f376000
size = BOOT_HEAP_SIZE

avoid[4]
stack: from end of heap
addr = 0x13f37dfff 
size = BOOT_STACK_SIZE;
> kernel: read done                           [ linux  9.55MiB  100%  7.25MiB/s ]
> params: [13fffc000,13fffffff]
> cmdline: [13fffb000,13fffb7fe]
> kernel: [13c000000,13f38cfff]
output_orig = 0x13c000000
output_size = 0x13f38cfff - 0x13c000000 = 0x338d000
> initrd: [139d7c000,13bfff7e3]
> initrd: read 1 file done             [ initrd.img  34.51MiB  100%  11.17MiB/s ]
> early console in decompress_kernel
> KASLR using RDTSC...
> decompress_kernel:
>   input: [0x13e9ed3b4-0x13f36a64b], output: 0x16c000000, heap:

It's very weird to get 0x16c000000 which is out of bound obviously.


> [0x13f376000-0x13f37dfff]
> 
> Decompressing Linux... xz...
> 
> XZ-compressed data is corrupt
> 
>  -- System halted
> 
> 13c000000 is loaded address.
> 0x13e9ed3b4 is the copied address, and decompress_kernel will use it as input.
> output is back to 13c000000 if aslr is not used.
> 
> 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/