Baoquan He <bhe@xxxxxxxxxx> writes: > On 01/13/25 at 12:01pm, Kirill A. Shutemov wrote: >> On Fri, Dec 13, 2024 at 05:49:30PM +0800, Yan Zhao wrote: >> > Hi Eric, >> > >> > This is a repost of the patch "kexec_core: Accept unaccepted kexec >> > destination addresses" [1], rebased to v6.13-rc2. >> >> Can we get this patch applied? > > This looks good to me. In v1, we have analyzed all other possible > solutions, however change in this patch seems the simplest and most > accepatable one. Truly? I will go back and look and see what I missed but I haven't seen anything that I addressed my original objections. To repeat my objection. The problem I saw was that the performance of the accepted memory paradigm was so terrible that they had to resort to lazily ``accepting'' memory, which leads to hacks in kexec. I would not like to included hacks in kexec just so that other people can avoid fixing their bugs. I did see a coherent explanation of the bad performance that pointed the finger squarely at the fact that everything is happening a page at a time. AKA that the design of the ACPI interface has a flaw that needs to be fixed. I really don't think we should be making complicated work-arounds for someone else's bad software decision just because someone immortalized their bad decision in a standard. Just accepting all of memory and letting the folks who made the bad decision deal with the consequences seems much more reasonable to me. > If Eric has no objection, maybe Andrew can help pick this into his > tree. I have a new objection. I believe ``unaccepted memory'' and especially lazily initialized ``unaccepted memory'' is an information leak that could defeat the purpose of encrypted memory. For that reason I have Cc'd the security list. I don't know who to CC to get expertise on this issue, and the security list folks should. Unless I am misunderstanding things the big idea with encrypted memory is that the hypervisor won't be able to figure out what you are doing, because it can't read your memory. My concern is that by making the ``acceptance'' of memory lazy, that there is a fairly strong indication of the function of different parts of memory. I expect that signal is strong enough to defeat whatever elements of memory address randomization that we implement in the kernel. So not only does it appear to me that implementation of ``accepting'' memory has a stupidly slow implementation, somewhat enshrined by a bad page at a time ACPI standard, but it appears to me that lazily ``accepting'' that memory probably defeats the purpose of having encrypted memory. I think the actual solution is to remove all code except for the "accept_memory=eager" code paths. AKA delete the "accept_memory=lazy" code. At that point there are no more changes that need to be made to kexec. Eric
