kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Jason Yan <yanaijie@huawei.com>
To: Scott Wood <oss@buserror.net>, <mpe@ellerman.id.au>,
	<linuxppc-dev@lists.ozlabs.org>, <diana.craciun@nxp.com>,
	<christophe.leroy@c-s.fr>, <benh@kernel.crashing.org>,
	<paulus@samba.org>, <npiggin@gmail.com>, <keescook@chromium.org>,
	<kernel-hardening@lists.openwall.com>
Cc: <wangkefeng.wang@huawei.com>, <linux-kernel@vger.kernel.org>,
	<jingxiangfeng@huawei.com>, <zhaohongjiang@huawei.com>,
	<thunder.leizhen@huawei.com>, <yebin10@huawei.com>
Subject: Re: [PATCH v7 00/12] implement KASLR for powerpc/fsl_booke/32
Date: Wed, 9 Oct 2019 16:41:59 +0800	[thread overview]
Message-ID: <90bb659a-bde4-3b8e-8f01-bf22d7534f44@huawei.com> (raw)
In-Reply-To: <38141b946f3376ce471e46eaf065e357ac540354.camel@buserror.net>

Hi Scott,

On 2019/10/9 15:13, Scott Wood wrote:
> On Wed, 2019-10-09 at 14:10 +0800, Jason Yan wrote:
>> Hi Scott,
>>
>> Would you please take sometime to test this?
>>
>> Thank you so much.
>>
>> On 2019/9/24 13:52, Jason Yan wrote:
>>> Hi Scott,
>>>
>>> Can you test v7 to see if it works to load a kernel at a non-zero address?
>>>
>>> Thanks,
> 
> Sorry for the delay.  Here's the output:
> 

Thanks for the test.

> ## Booting kernel from Legacy Image at 10000000 ...
>     Image Name:   Linux-5.4.0-rc2-00050-g8ac2cf5b4
>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>     Data Size:    7521134 Bytes = 7.2 MiB
>     Load Address: 04000000
>     Entry Point:  04000000
>     Verifying Checksum ... OK
> ## Flattened Device Tree blob at 1fc00000
>     Booting using the fdt blob at 0x1fc00000
>     Uncompressing Kernel Image ... OK
>     Loading Device Tree to 07fe0000, end 07fff65c ... OK
> KASLR: No safe seed for randomizing the kernel base.
> OF: reserved mem: initialized node qman-fqd, compatible id fsl,qman-fqd
> OF: reserved mem: initialized node qman-pfdr, compatible id fsl,qman-pfdr
> OF: reserved mem: initialized node bman-fbpr, compatible id fsl,bman-fbpr
> Memory CAM mapping: 64/64/64 Mb, residual: 12032Mb

When boot from 04000000, the max CAM value is 64M. And
you have a board with 12G memory, CONFIG_LOWMEM_CAM_NUM=3 means only
192M memory is mapped and when kernel is randomized at the middle of 
this 192M memory, we will not have enough continuous memory for node map.

Can you set CONFIG_LOWMEM_CAM_NUM=8 and see if it works?

Thanks.

> Linux version 5.4.0-rc2-00050-g8ac2cf5b4e4a-dirty (scott@snotra) (gcc version 8.
> 1.0 (GCC)) #26 SMP Wed Oct 9 01:50:40 CDT 2019
> Using CoreNet Generic machine description
> printk: bootconsole [udbg0] enabled
> CPU maps initialized for 1 thread per core
> -----------------------------------------------------
> phys_mem_size     = 0x2fc000000
> dcache_bsize      = 0x40
> icache_bsize      = 0x40
> cpu_features      = 0x00000000000003b4
>    possible        = 0x00000000010103bc
>    always          = 0x0000000000000020
> cpu_user_features = 0x8c008000 0x08000000
> mmu_features      = 0x000a0010
> physical_start    = 0xc7c4000
> -----------------------------------------------------
> CoreNet Generic board
> mpc85xx_qe_init: Could not find Quicc Engine node
> barrier-nospec: using isync; sync as speculation barrier
> Zone ranges:
>    Normal   [mem 0x0000000004000000-0x000000000fffffff]
>    HighMem  [mem 0x0000000010000000-0x00000002ffffffff]
> Movable zone start for each node
> Early memory node ranges
>    node   0: [mem 0x0000000004000000-0x00000002ffffffff]
> Initmem setup node 0 [mem 0x0000000004000000-0x00000002ffffffff]
> Kernel panic - not syncing: Failed to allocate 125173760 bytes for node 0 memory
>   map
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.0-rc2-00050-g8ac2cf5b4e4a-dirty #26
> Call Trace:
> [c989fe10] [c924bfb0] dump_stack+0x84/0xb4 (unreliable)
> [c989fe30] [c880badc] panic+0x140/0x334
> [c989fe90] [c89a1144] alloc_node_mem_map.constprop.117+0xa0/0x11c
> [c989feb0] [c95481c4] free_area_init_node+0x314/0x5b8
> [c989ff30] [c9548b34] free_area_init_nodes+0x57c/0x5c0
> [c989ff80] [c952cbb4] setup_arch+0x250/0x270
> [c989ffa0] [c95278e0] start_kernel+0x74/0x4e8
> [c989fff0] [c87c4478] set_ivor+0x150/0x18c
> Kernel Offset: 0x87c4000 from 0xc0000000
> Rebooting in 180 seconds..
> 
> -Scott
> 
> 
> 
> .
> 


  reply	other threads:[~2019-10-09  8:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20  9:45 [PATCH v7 00/12] implement KASLR for powerpc/fsl_booke/32 Jason Yan
2019-09-20  9:45 ` [PATCH v7 01/12] powerpc: unify definition of M_IF_NEEDED Jason Yan
2019-09-20  9:45 ` [PATCH v7 02/12] powerpc: move memstart_addr and kernstart_addr to init-common.c Jason Yan
2019-09-20  9:45 ` [PATCH v7 03/12] powerpc: introduce kernstart_virt_addr to store the kernel base Jason Yan
2019-09-20  9:45 ` [PATCH v7 04/12] powerpc/fsl_booke/32: introduce create_kaslr_tlb_entry() helper Jason Yan
2019-09-20  9:45 ` [PATCH v7 05/12] powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper Jason Yan
2019-09-20  9:45 ` [PATCH v7 06/12] powerpc/fsl_booke/32: implement KASLR infrastructure Jason Yan
2019-09-20  9:45 ` [PATCH v7 07/12] powerpc/fsl_booke/32: randomize the kernel image offset Jason Yan
2019-09-20  9:45 ` [PATCH v7 08/12] powerpc/fsl_booke/kaslr: clear the original kernel if randomized Jason Yan
2019-09-20  9:45 ` [PATCH v7 09/12] powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter Jason Yan
2019-09-20  9:45 ` [PATCH v7 10/12] powerpc/fsl_booke/kaslr: dump out kernel offset information on panic Jason Yan
2019-09-20  9:45 ` [PATCH v7 11/12] powerpc/fsl_booke/kaslr: export offset in VMCOREINFO ELF notes Jason Yan
2019-09-20  9:45 ` [PATCH v7 12/12] powerpc/fsl_booke/32: Document KASLR implementation Jason Yan
2019-09-24  5:52 ` [PATCH v7 00/12] implement KASLR for powerpc/fsl_booke/32 Jason Yan
2019-10-09  6:10   ` Jason Yan
2019-10-09  7:13     ` Scott Wood
2019-10-09  8:41       ` Jason Yan [this message]
2019-10-09 18:46         ` Scott Wood
2019-10-21  3:34           ` Jason Yan
2019-10-22 23:22             ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=90bb659a-bde4-3b8e-8f01-bf22d7534f44@huawei.com \
    --to=yanaijie@huawei.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=diana.craciun@nxp.com \
    --cc=jingxiangfeng@huawei.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=oss@buserror.net \
    --cc=paulus@samba.org \
    --cc=thunder.leizhen@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=yebin10@huawei.com \
    --cc=zhaohongjiang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).