linux-kernel - Re: [PATCH 06/12] x86/mm: Enable and use the arch_pgd_init

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:	Sun, 14 Jun 2015 22:54:12 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	linux-kernel@...r.kernel.org, linux-mml@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Brian Gerst <brgerst@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Waiman Long <Waiman.Long@...com>
Subject: Re: [PATCH 06/12] x86/mm: Enable and use the arch_pgd_init_late()
	method

On 06/14, Ingo Molnar wrote:
>
> So since we have a spin_lock() there already,

Yeeeees, I thought about task_lock() or pgd_lock too.

> Also, since this is x86 specific code we could rely on the fact that
> spinlock-acquire is a full memory barrier?

we do not really need the full barrier if we rely on spinlock_t,
we can rely on acquire+release semantics.

Lets forget about exec_mmap(). If we add, say,

	// or unlock_wait() + barriers
	task_lock(current->group_leader);
	task_unlock(current->group_leader);

at the start of arch_pgd_init_late() we will fix the problems with
fork() even if pgd_none() below can leak into the critical section.

We rely on the fact that find_lock_task_mm() does lock/unlock too
and always starts with the group leader.

If sync_global_pgds() takes this lock first, we must see the change
in *PGD after task_unlock(). Actually right after task_lock().

Otherwise, sync_global_pgds() should see the result of list addition
if it takes this (the same) ->group_leader->lock_alloc after us.

But this is not nice, and exec_mmap() calls arch_pgd_init_late() under
task_lock().

So, unless you are going to remove pgd_lock altogether perhaps we can
rely on it the same way

	mb();
	spin_unlock_wait(&pgd_lock);
	rmb();

Avoids the barriers (and comments) on another side, but I can't say
I really like this...

So I won't argue with 2 mb's on both sides.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/