linux-kernel - Re: [RFC V1 5/5] x86: CVMs: Ensure that memory conversions happen at 2M alignment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 2 Feb 2024 08:35:58 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Vishal Annapurve <vannapurve@...gle.com>,
 Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, pbonzini@...hat.com,
 rientjes@...gle.com, seanjc@...gle.com, erdemaktas@...gle.com,
 ackerleytng@...gle.com, jxgao@...gle.com, sagis@...gle.com,
 oupton@...gle.com, peterx@...hat.com, vkuznets@...hat.com,
 dmatlack@...gle.com, pgonda@...gle.com, michael.roth@....com,
 kirill@...temov.name, thomas.lendacky@....com, dave.hansen@...ux.intel.com,
 linux-coco@...ts.linux.dev, chao.p.peng@...ux.intel.com,
 isaku.yamahata@...il.com, andrew.jones@...ux.dev, corbet@....net,
 hch@....de, m.szyprowski@...sung.com, rostedt@...dmis.org,
 iommu@...ts.linux.dev
Subject: Re: [RFC V1 5/5] x86: CVMs: Ensure that memory conversions happen at
 2M alignment

On 2/2/24 08:22, Vishal Annapurve wrote:
>> If you must - focus on getting swiotlb conversions to happen at the desired
>> granularity but don't try to force every single conversion to be >4K.
> If any conversion within a guest happens at 4K granularity, then this
> will effectively cause non-hugepage aligned EPT/NPT entries. This
> series is trying to get all private and shared memory regions to be
> hugepage aligned to address the problem statement.

Yeah, but the series is trying to do that by being awfully myopic at
this stage and without being _declared_ to be so myopic.

Take a look at all of the set_memory_decrypted() calls.  How many of
them even operate on the part of the guest address space rooted in the
memfd where splits matter?  They're not doing conversions.  They're just
setting up shared mappings in the page tables of gunk that was never
private in the first place.