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:   Thu, 16 Jul 2020 19:06:20 -0300
From:   Thiago Jung Bauermann <bauerman@...ux.ibm.com>
To:     Hari Bathini <hbathini@...ux.ibm.com>
Cc:     kernel test robot <lkp@...el.com>, Pingfan Liu <piliu@...hat.com>,
        Nayna Jain <nayna@...ux.ibm.com>,
        Kexec-ml <kexec@...ts.infradead.org>,
        Mahesh J Salgaonkar <mahesh@...ux.ibm.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        lkml <linux-kernel@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...abs.org>,
        Sourabh Jain <sourabhjain@...ux.ibm.com>,
        Petr Tesarik <ptesarik@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dave Young <dyoung@...hat.com>,
        Vivek Goyal <vgoyal@...hat.com>,
        Eric Biederman <ebiederm@...ssion.com>
Subject: Re: [PATCH v3 09/12] ppc64/kexec_file: setup backup region for kdump kernel


Hari Bathini <hbathini@...ux.ibm.com> writes:

> On 16/07/20 7:08 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@...ux.ibm.com> writes:
>>
>>> @@ -968,7 +1040,7 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>>
>>>  	/*
>>>  	 * Restrict memory usage for kdump kernel by setting up
>>> -	 * usable memory ranges.
>>> +	 * usable memory ranges and memory reserve map.
>>>  	 */
>>>  	if (image->type == KEXEC_TYPE_CRASH) {
>>>  		ret = get_usable_memory_ranges(&umem);
>>> @@ -980,6 +1052,24 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>>  			pr_err("Error setting up usable-memory property for kdump kernel\n");
>>>  			goto out;
>>>  		}
>>> +
>>> +		ret = fdt_add_mem_rsv(fdt, BACKUP_SRC_START + BACKUP_SRC_SIZE,
>>> +				      crashk_res.start - BACKUP_SRC_SIZE);
>>
>> I believe this answers my question from the other email about how the
>> crashkernel is prevented from stomping in the crashed kernel's memory,
>> right? I needed to think for a bit to understand what the above
>> reservation was protecting. I think it's worth adding a comment.
>
> Right. The reason to add it in the first place is, prom presses the panic button if
> it can't find low memory. Marking it reserved seems to keep it quiet though. so..
>
> Will add comment mentioning that..

Ah, makes sense. Thanks for the explanation.

>>> +void purgatory(void)
>>> +{
>>> +	void *dest, *src;
>>> +
>>> +	src = (void *)BACKUP_SRC_START;
>>> +	if (backup_start) {
>>> +		dest = (void *)backup_start;
>>> +		__memcpy(dest, src, BACKUP_SRC_SIZE);
>>> +	}
>>> +}
>>
>> In general I'm in favor of using C code over assembly, but having to
>> bring in that relocation support just for the above makes me wonder if
>> it's worth it in this case.
>
> I am planning to build on purgatory later with "I'm in purgatory" print support
> for pseries at least and also, sha256 digest check.

Ok. In that case, my preference would be to convert both the powerpc and
x86 purgatories to PIE since this greatly reduces the types of
relocations that are emitted, but better ask Dave Young what he thinks
before going down that route.

--
Thiago Jung Bauermann
IBM Linux Technology Center

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ