On Thu, Feb 13, 2025 at 07:55:15AM -0800, Dave Hansen wrote: > 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. I only have 128GB machine readily available and posted some number on other thread[1]: On single vCPU it takes about a minute to accept 90GiB of memory. It improves a bit with number of vCPUs. It is 40 seconds with 4 vCPU, but it doesn't scale past that in my setup. I've mentioned it before in other thread: [1] https://lore.kernel.org/all/ihzvi5pwn5hrn4ky2ehjqztjxoixaiaby4igmeihqfehy2vrii@tsg6j5qvmyrm -- Kiryl Shutsemau / Kirill A. Shutemov
