On 1/13/25 06:59, Eric W. Biederman wrote: ... > 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. At a super high level, you are right. Accepting memory tells the hypervisor that the guest is _allocating_ memory. It even tells the host what the guest physical address of the memory is. But that's far below the standard we've usually exercised in the kernel for rejecting on security concerns. Did anyone on the security list raise any issues here? I've asked them about a few things in the past and usually I've thought that no news is good news. > 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. In the end, the information that the hypervisor gets is that the guest allocated _some_ page within a 4MB physical region and the time. It gets that signal once per boot for each region. It will mostly see a pattern of acceptance going top-down from high to low physical addresses. The hypervisor never learns anything about KASLR. The fact that the physical allocation patterns are predictable (with or without memory acceptance) is one of the reasons KASLR is in place. I don't think memory acceptance has any real impact on "memory address randomization". This is especially true because it's a once-per-boot signal, not a continuous thing that can be leveraged. 4MB is also awfully coarse. > 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. Memory acceptance is pitifully slow. But it's slow because it fundamentally requires getting guest memory into a known state before guest use. You either have slow memory acceptance as a thing or you have slow guest boot. Are there any other CoCo systems that don't have to zero memory like TDX does? On the x86 side, we have SGX the various flavors of SEV. They all, as far as I know, require some kind of slow "conversion" process when pages change security domains. > 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. That was my first instinct too: lazy acceptance is too complicated to live and must die. It sounds like you're advocating for the "slow guest boot" option. Kirill, can you remind us how fast a guest boots to the shell for modestly-sized (say 256GB) memory with "accept_memory=eager" versus "accept_memory=lazy"? IIRC, it was a pretty remarkable difference. Eric, I wasn't planning on ripping the lazy acceptance code out of arch/x86. I haven't heard any rumblings from the mm folks that it's causing problems over there either. This seems like something we want to fix and I _think_ the core kexec code is the right place to fix this issue. There are definitely ways to work around this in arch code, but they seem rather distasteful and I'd rather not go there.
