linux-kernel - Re: [PATCH 1/2 v6] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name

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, 15 Nov 2018 13:44:07 +0800
From:   lijiang <lijiang@...hat.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
        x86@...nel.org, tglx@...utronix.de, mingo@...hat.com,
        akpm@...ux-foundation.org, dyoung@...hat.com, bhe@...hat.com
Subject: Re: [PATCH 1/2 v6] x86/kexec_file: add e820 entry in case e820 type
 string matches to io resource name

在 2018年11月14日 19:26, Borislav Petkov 写道:
> On Wed, Nov 14, 2018 at 03:29:25PM +0800, Lianbo Jiang wrote:
>> When load the kernel image and initramfs by kexec_file_load syscall, it can
>> not add exact e820 reserved type to kdump kernel e820 table.
>>
>> Kdump uses walk_iomem_res_desc() to iterate io resources, then adds matched
>> desc to e820 table for kdump kernel. But, when convert the e820 type into
>> the iores descriptors, several e820 types are converted to 'IORES_DES_NONE'
>> in this function e820_type_to_iores_desc(). So the walk_iomem_res_desc()
>> will get these unnecessary types(E820_TYPE_RAM/E820_TYPE_UNUSABLE/E820_TYPE
>> _KERN) when iterate io resources by the 'IORES_DES_NONE'.
>>
>> It needs filter out these redundant type(such as E820_TYPE_RAM/E820_TYPE_
>> UNUSABLE/E820_TYPE_KERN) in order to add exact e820 reserved type to kdump
>> kernel e820 table. Thus it also needs an extra checking in memmap_entry_
>> callback() to match the e820 type and resource name.
> 
> Ok, it took me a while to parse what this is trying to say so let's
> start from the top:
> 
> * What resource type do you do need in the second kernel?
> 

Thanks for your comment.

The e820 reserved ranges need to be passed to the second kernel.

> * The most important question: why?
> 

At present, the upstream kernel does not pass the e820 reserved ranges to the
second kernel, which might cause two problems:

The first one is the MMCONFIG issue, the PCI MMCONFIG(extended mode) requires
the reserved region otherwise it falls back to legacy mode, which might lead to
the hot-plug device could not be recognized in kdump kernel.

Another one is that the e820 reserved ranges do not setup in kdump kernel, which
could cause kdump can't work in some machines. To know more information, please
refer to the [PATCH 2/2 v6] patch log.

> * If it is the reserved resource, why aren't you adding
> IORES_DESC_RESERVED or so which to look for instead of this hacky string
> comparison?
> 

Adding the new descriptor 'IORES_DESC_RESERVED' is also a good solution. I will
modify these patches based on your suggestion and post again.

Thanks.
Lianbo