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 07:55:05 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Pasha Tatashin <pasha.tatashin@...een.com>, Nikolay Borisov
	<nik.borisov@...e.com>
CC: "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()



Le 12/03/2024 à 17:53, Pasha Tatashin a écrit :
> On Tue, Mar 12, 2024 at 3:16 AM Nikolay Borisov <nik.borisov@...e.com> wrote:
>>
>>
>>
>> On 11.03.24 г. 18:46 ч., Pasha Tatashin wrote:
>>> In preporation for dynamic kernel stacks do not zero the whole span of
>>> the stack, but instead only the pages that are part of the vm_area.
>>>
>>> This is because with dynamic stacks we might have only partially
>>> populated stacks.
>>>
>>> Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
>>> ---
>>>    kernel/fork.c | 6 ++++--
>>>    1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/fork.c b/kernel/fork.c
>>> index 6a2f2c85e09f..41e0baee79d2 100644
>>> --- a/kernel/fork.c
>>> +++ b/kernel/fork.c
>>> @@ -263,8 +263,8 @@ static int memcg_charge_kernel_stack(struct vm_struct *vm)
>>>    static int alloc_thread_stack_node(struct task_struct *tsk, int node)
>>>    {
>>>        struct vm_struct *vm_area;
>>> +     int i, j, nr_pages;
>>>        void *stack;
>>> -     int i;
>>>
>>>        for (i = 0; i < NR_CACHED_STACKS; i++) {
>>>                vm_area = this_cpu_xchg(cached_stacks[i], NULL);
>>> @@ -282,7 +282,9 @@ static int alloc_thread_stack_node(struct task_struct *tsk, int node)
>>>                stack = kasan_reset_tag(vm_area->addr);
>>>
>>>                /* Clear stale pointers from reused stack. */
>>> -             memset(stack, 0, THREAD_SIZE);
>>> +             nr_pages = vm_area->nr_pages;
>>> +             for (j = 0; j < nr_pages; j++)
>>> +                     clear_page(page_address(vm_area->pages[j]));
>>
>> Can't this be memset(stack, 0, nr_pages*PAGE_SIZE) ?
> 
> No, we can't, because the pages can be physically discontiguous.
> 

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

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.

Nevertheless, from powerpc point of view I'm happy with clear_page() 
which is more optimised than memset(0)

Christophe