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: Tue, 16 Jan 2024 22:12:26 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Michael Roth <michael.roth@....com>
Cc: Dave Hansen <dave.hansen@...el.com>,
	Tom Lendacky <thomas.lendacky@....com>,
	Borislav Petkov <bp@...en8.de>, x86@...nel.org, kvm@...r.kernel.org,
	linux-coco@...ts.linux.dev, linux-mm@...ck.org,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...hat.com, jroedel@...e.de,
	hpa@...or.com, ardb@...nel.org, pbonzini@...hat.com,
	seanjc@...gle.com, vkuznets@...hat.com, jmattson@...gle.com,
	luto@...nel.org, dave.hansen@...ux.intel.com, slp@...hat.com,
	pgonda@...gle.com, peterz@...radead.org,
	srinivas.pandruvada@...ux.intel.com, rientjes@...gle.com,
	tobin@....com, vbabka@...e.cz, kirill@...temov.name,
	ak@...ux.intel.com, tony.luck@...el.com,
	sathyanarayanan.kuppuswamy@...ux.intel.com, alpergun@...gle.com,
	jarkko@...nel.org, ashish.kalra@....com, nikunj.dadhania@....com,
	pankaj.gupta@....com, liam.merwick@...cle.com, zhi.a.wang@...el.com,
	Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH v1 11/26] x86/sev: Invalidate pages from the direct map
 when adding them to the RMP table

On Tue, Jan 16, 2024 at 10:50:25AM -0600, Michael Roth wrote:
> On Tue, Jan 16, 2024 at 10:19:09AM -0600, Michael Roth wrote:
> > 
> > The downside of course is potential impact for non-SNP workloads
> > resulting from splitting the directmap. Mike Rapoport's numbers make
> > me feel a little better about it, but I don't think they apply directly
> > to the notion of splitting the entire directmap. It's Even he LWN article
> > summarizes:

When I ran the tests, I had the entire direct map forced to 4k or 2M pages.
There is indeed some impact and some tests suffer more than others but
there were also runs that benefit from smaller page size in the direct map,
at least if I remember correctly the results Intel folks posted a while
ago.
 
> >   "The conclusion from all of this, Rapoport continued, was that
> >   direct-map fragmentation just does not matter — for data access, at
> >   least. Using huge-page mappings does still appear to make a difference
> >   for memory containing the kernel code, so allocator changes should
> >   focus on code allocations — improving the layout of allocations for
> >   loadable modules, for example, or allowing vmalloc() to allocate huge
> >   pages for code. But, for kernel-data allocations, direct-map
> >   fragmentation simply appears to not be worth worrying about."
> > 
> > So at the very least, if we went down this path, we would be worth
> > investigating the following areas in addition to general perf testing:
> > 
> >   1) Only splitting directmap regions corresponding to kernel-allocatable
> >      *data* (hopefully that's even feasible...)

Forcing the direct map to 4k pages does not affect the kernel text
mappings, they are created separately and they are not the part of the
kernel mapping of the physical memory.
Well, except the modules, but they are mapped with 4k pages anyway.

> -Mike

-- 
Sincerely yours,
Mike.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ