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: <8FA16E6F-19A7-4E46-A21D-A31B6BFF1B8E@flygoat.com>
Date:   Sat, 19 Sep 2020 18:17:21 +0800
From:   Jiaxun Yang <jiaxun.yang@...goat.com>
To:     Youling Tang <tangyouling@...ngson.cn>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>
CC:     linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: kexec: Add crashkernel=YM handling



于 2020年9月19日 GMT+08:00 下午4:29:39, Youling Tang <tangyouling@...ngson.cn> 写到:
>
>
>On 09/19/2020 03:02 PM, Jiaxun Yang wrote:
>>
>> 于 2020年9月19日 GMT+08:00 上午9:55:46, Youling Tang <tangyouling@...ngson.cn> 写到:
>>> When the kernel crashkernel parameter is specified with just a size,
>>> we are supposed to allocate a region from RAM to store the crashkernel.
>>> However, MIPS merely reserves physical address zero with no checking
>>> that there is even RAM there.
>>>
>>> Fix this by lifting similar code from x86, importing it to MIPS with the
>>> MIPS specific parameters added. In the absence of any platform specific
>>> information, we allocate the crashkernel region from the first 512MB of
>>> physical memory (limited to CKSEG0 or KSEG0 address range).
>>>
>>> When X is not specified, crash_base defaults to 0 (crashkernel=YM@XM).
>>>
>>> E.g. without this patch:
>>>
>>> The environment as follows:
>>> [    0.000000] MIPS: machine is loongson,loongson64c-4core-ls7a
>>> ...
>>> [    0.000000] Kernel command line: root=/dev/sda2 crashkernel=96M ...
>>>
>>> The warning as follows:
>>> [    0.000000] Invalid memory region reserved for crash kernel
>>>
>>> And the iomem as follows:
>>> 00200000-0effffff : System RAM
>>>   00200000-00b47f87 : Kernel code
>>>   00b47f88-00dfffff : Kernel data
>>>   00e60000-01f73c7f : Kernel bss
>>> 1a000000-1bffffff : pci@...00000
>>> ...
>>>
>>> With this patch:
>>>
>>> After increasing crash_base <= 0 handling.
>>>
>>> And the iomem as follows:
>>> 00200000-0effffff : System RAM
>>>   00200000-00b47f87 : Kernel code
>>>   00b47f88-00dfffff : Kernel data
>>>   00e60000-01f73c7f : Kernel bss
>>>   04000000-09ffffff : Crash kernel
>>> 1a000000-1bffffff : pci@...00000
>>> ...
>>>
>>> Signed-off-by: Youling Tang <tangyouling@...ngson.cn>
>>> ---
>>> arch/mips/kernel/setup.c | 24 +++++++++++++++++++++---
>>> 1 file changed, 21 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>>> index bf5f5ac..59a88ea 100644
>>> --- a/arch/mips/kernel/setup.c
>>> +++ b/arch/mips/kernel/setup.c
>>> @@ -477,6 +477,11 @@ early_param("elfcorehdr", early_parse_elfcorehdr);
>>> #endif
>>>
>>> #ifdef CONFIG_KEXEC
>>> +
>>> +/* 64M alignment for crash kernel regions */
>>> +#define CRASH_ALIGN	SZ_64M
>>> +#define CRASH_ADDR_MAX	SZ_512M
>> Hi Youling
>>
>> How do you determine the alignment requirement?
>>
>> Can we relax it?
>>
>> Thanks.
>>
>> - Jiaxun
>Hi Jiaxun
>
>Only when XM is not specified, 64M alignment is specified.
>
>After the capture kernel is configured with CRASH_DUMP, PHYSICAL_START
>defaults to 0x0xffffffff84000000 (64M). The kexec -p operation will
>succeed only when the reserved Crash kernel start address is consistent
>with PHYSICAL_START.
>
>The description of PHYSICAL_START in arch/mips/Kconfig:2996 is as follows:
>This gives the CKSEG0 or KSEG0 address where the kernel is loaded.If you
>plan to use kernel for capturing the crash dump change this value to start
>of the reserved region (the "X" value as specified in the 
>"crashkernel=YM@XM"
>command line boot parameter passed to the panic-ed kernel).

Thanks for your explanation~

That makes sense.

- Jiaxun


>
>Thanks,
>
>- Youling

[...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ