> 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 We essentially rely on lazy acceptance support for reducing SNP guest boot time. Here are some performance numbers for SNP guests which i have here after discussing with Michael Roth (who is also CCed here): Just did quick boot of a 128GB SNP guest with accept_memory=lazy guest kernel parameter and that took 22s to boot, and with accept_memory=eager it takes 3 minutes and 47s, so it is a remarkable difference. Thanks, Ashish >-- > Kiryl Shutsemau / Kirill A. Shutemov
