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] [day] [month] [year] [list]
Message-Id: <1657104347.v93p7p5tyq.naveen@linux.ibm.com>
Date:   Wed, 06 Jul 2022 16:30:56 +0530
From:   "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
To:     Baoquan He <bhe@...hat.com>, Coiby Xu <coxu@...hat.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Eric Biederman <ebiederm@...ssion.com>,
        kexec@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] kexec_file: Drop weak attribute from functions

Hi Coiby,

Coiby Xu wrote:
> Hi Baoquan and Naveen,
> 
> On Mon, Jul 04, 2022 at 12:10:00PM +0800, Baoquan He wrote:
>>On 07/01/22 at 01:04pm, Naveen N. Rao wrote:
>>> Drop __weak attribute from functions in kexec_file.c:
>>> - arch_kexec_kernel_image_probe()
>>> - arch_kimage_file_post_load_cleanup()
>>> - arch_kexec_kernel_image_load()
>>> - arch_kexec_locate_mem_hole()
>>> - arch_kexec_kernel_verify_sig()
>>>
>>> arch_kexec_kernel_image_load() calls into kexec_image_load_default(), so
>>> drop the static attribute for the latter.
>>>
>>> arch_kexec_kernel_verify_sig() is not overridden by any architecture, so
>>> drop the __weak attribute.
>>
>>The dropping of arch_kexec_kernel_verify_sig() conflicts with patch 1 of
>>anotherpatchset, and the other patches in the patchset depends on the
>>patch 1.
>>
>>[PATCH v9 0/4] unify the keyrings of arm64 and s390 with x86 to verify kexec'ed kernel signature
>>
>>Hi, Naveen, Coiby,
>>
>>Please negotiate how to solve the conflict.
> 
> Thanks Baoquan for letting me know of this conflict. Naveen, how about
> resolving the conflict based on which patch is merged first? If your
> patch set is going to be merged early, I will resolve the conflict in my
> patch set, and vice versa.

Sure, that's fair. It looks like Andrew has queued up this series 
though:
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/log/?h=mm-nonmm-unstable

The conflict itself is trivial, so it should be straightforward to 
address it.


Thanks,
Naveen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ