linux-kernel - Re: [RFC 06/14] fork: zero vmap stack using clear

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: Thu, 14 Mar 2024 09:52:29 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Nikolay Borisov <nik.borisov@...e.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, 
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "x86@...nel.org" <x86@...nel.org>, 
	"bp@...en8.de" <bp@...en8.de>, "brauner@...nel.org" <brauner@...nel.org>, 
	"bristot@...hat.com" <bristot@...hat.com>, "bsegall@...gle.com" <bsegall@...gle.com>, 
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, 
	"dianders@...omium.org" <dianders@...omium.org>, 
	"dietmar.eggemann@....com" <dietmar.eggemann@....com>, 
	"eric.devolder@...cle.com" <eric.devolder@...cle.com>, "hca@...ux.ibm.com" <hca@...ux.ibm.com>, 
	"hch@...radead.org" <hch@...radead.org>, "hpa@...or.com" <hpa@...or.com>, 
	"jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>, "jgg@...pe.ca" <jgg@...pe.ca>, 
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>, "jroedel@...e.de" <jroedel@...e.de>, 
	"juri.lelli@...hat.com" <juri.lelli@...hat.com>, 
	"kent.overstreet@...ux.dev" <kent.overstreet@...ux.dev>, "kinseyho@...gle.com" <kinseyho@...gle.com>, 
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, "lstoakes@...il.com" <lstoakes@...il.com>, 
	"luto@...nel.org" <luto@...nel.org>, "mgorman@...e.de" <mgorman@...e.de>, "mic@...ikod.net" <mic@...ikod.net>, 
	"michael.christie@...cle.com" <michael.christie@...cle.com>, "mingo@...hat.com" <mingo@...hat.com>, 
	"mjguzik@...il.com" <mjguzik@...il.com>, "mst@...hat.com" <mst@...hat.com>, 
	"npiggin@...il.com" <npiggin@...il.com>, "peterz@...radead.org" <peterz@...radead.org>, 
	"pmladek@...e.com" <pmladek@...e.com>, 
	"rick.p.edgecombe@...el.com" <rick.p.edgecombe@...el.com>, "rostedt@...dmis.org" <rostedt@...dmis.org>, 
	"surenb@...gle.com" <surenb@...gle.com>, "tglx@...utronix.de" <tglx@...utronix.de>, 
	"urezki@...il.com" <urezki@...il.com>, 
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>, "vschneid@...hat.com" <vschneid@...hat.com>
Subject: Re: [RFC 06/14] fork: zero vmap stack using clear_page() instead of memset()

> But the pages were already physically discontiguous before your change,
> what's the difference ?

Pages were not physically contiguous before my change. They were
allocated with __vmalloc_node_range() which allocates sparse pages and
maps them to a virtually contiguous span of memory within
[VMALLOC_START, VMALLOC_END) range.

> It doesn't matter that the pages are physically discontiguous as far as
> they are virtually contiguous, which should still be the case here for a
> stack.

This patch is a preparation patch for the "dynamic kernel stack"
feature, in the description it says:
This is because with dynamic stacks we might have only partially
populated stacks.

We could compute the populated part of the stack, and determine its
start and end mapped VA range by using vm_area->pages[] and
vm_area->nr_pages, but that would make code a little uglier especially
becuase we would need to take into the account if stack is growing up
or down.. Therefore, using clear_page()  is simpler and should be fast
enough.

Thanks,
Pasha