[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5007ae91-f4d5-430b-a403-aff9af1d6375@intel.com>
Date: Wed, 19 Feb 2025 15:16:14 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Yan Zhao <yan.y.zhao@...el.com>, ebiederm@...ssion.com
Cc: 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, bhe@...hat.com,
Andrew Morton <akpm@...ux-foundation.org>, Baoquan He <bhe@...hat.com>
Subject: Re: [PATCH v2 1/1] kexec_core: Accept unaccepted kexec segments'
destination addresses
On 12/13/24 01:54, Yan Zhao wrote:
> Accept the destination addresses during the kexec load, immediately after
> they pass sanity checks. This ensures the code is located in a common place
> shared by both the kexec_load and kexec_file_load system calls.
So, we've got an end-user-visible bug. Eric raised some good concerns
about the hardware and firmware design, but I think they've all been
addressed. The only other even solution I've seen proposed is to not do
unaccepted memory in the first place. I don't think that's viable or
justified, especially since we've got at least one end user[1] that
seems to think unaccepted memory fits their needs.
This bug can _probably_ be fixed in arch/x86 as well, but having the
solution in general code seems like the right place to me:
Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
Andrew, it seems like a lot of kexec work flows through you. Are you the
right one to pick this up?
1.
https://lore.kernel.org/all/CAMGD6P3r-S-Va-TRvVjZ808on9+-wFJ_VeTpQ+FEN1jBbhmnXw@mail.gmail.com/
Powered by blists - more mailing lists