On Mon, Jan 13, 2025 at 08:59:29AM -0600, Eric W. Biederman wrote: > 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. The interface of accepting memory is platform specific. EFI (not ACPI) only provides a way to enumerate which memory is unaccepted. > 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. Note that these work-arounds are needed only because kexec allocates memory in a hackish way bypassing page allocator. I don't like that unaccepted memory details leaks into kexec code either. But it happens because kexec is special and requires special handling. > > 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. It is outside of TDX (and I believe SEV) threat model. In TDX case, VMM can block access to arbitrary guest memory range which would cause TD-exit if guest touches it. The blocking is required to do some of memory maintenance operations, like promoting 4k pages to 2M or relocating a guest page to a different host physical address. Lazy memory accept doesn't change anything from security PoV here. -- Kiryl Shutsemau / Kirill A. Shutemov
