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: Sat, 3 Feb 2024 10:49:38 +0530
From: Vishal Annapurve <vannapurve@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>, 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 Fri, Feb 2, 2024 at 10:06 PM Dave Hansen <dave.hansen@...el.com> wrote:
>
> 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.
>

Agreed. I was being overly optimistic when I mentioned following in
the cover message:
"** This series leaves out some of the conversion sites which might not
be 2M aligned but should be easy to fix once the approach is finalized. **"

> 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.

Thinking it over again, yeah the conversions that are happening
outside SWIOTLB should be impacting significantly less memory ranges.
As Jeremi and you are suggesting, it would be a big step forward if
memory conversions happening for just DMA requests are aligned to
hugepage sizes.