linux-kernel - Re: [PATCH] kexec_core: Accept unaccepted kexec destination addresses

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: <Z1AesNxMFwuZQ7WY@yzhao56-desk.sh.intel.com>
Date: Wed, 4 Dec 2024 17:19:44 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: Baoquan He <bhe@...hat.com>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>, "Kirill A. Shutemov"
	<kirill@...temov.name>, <kexec@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <linux-coco@...ts.linux.dev>,
	<x86@...nel.org>, <rick.p.edgecombe@...el.com>,
	<kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH] kexec_core: Accept unaccepted kexec destination addresses

On Tue, Dec 03, 2024 at 06:30:36PM +0800, Baoquan He wrote:
> On 12/03/24 at 06:06pm, Yan Zhao wrote:
> > On Mon, Dec 02, 2024 at 10:17:16PM +0800, Baoquan He wrote:
> > > On 11/29/24 at 01:52pm, Yan Zhao wrote:
> > > > On Thu, Nov 28, 2024 at 11:19:20PM +0800, Baoquan He wrote:
...
> > > Oh, I just said the opposite. I meant we could search according to the
> > > current unaccepted->bitmap to make sure the destination area definitely
> > > have been accepted. This is the best if doable, while I know it's not
> > > easy.
> > Well, this sounds like introducing a new constraint in addition to the current
> > checking of !kimage_is_destination_range() in locate_mem_hole_top_down() or
> > locate_mem_hole_bottom_up(). (powerpc also has a different implementation).
> > 
> > This could make the success unpredictable, depending on how many pages have
> > been accepted by the 1st kernel and the layout of the accepted pages(e.g.,
> > whether they are physically contiguous). The 1st kernel would also have no
> > reliable way to ensure success except by accepting all the guest pages.
> 
> Yeah, when I finished reading accept_memory code, this is the first idea
> which come up into my mind. If it can be made, it's the most ideal. When
> I tried to make a draft change, it does introduce a lot of code change and
> add very much complication and I just gave up.
> 
> Maybe this can be added to cover-letter too to tell this possible path we
> explored.
Ok.