linux-kernel - Re: remap allocator for per-CPU memory

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:	Wed, 13 May 2009 13:46:47 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Tejun Heo <teheo@...ell.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Jan Beulich <JBeulich@...ell.com>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: remap allocator for per-CPU memory

> I couldn't find anything explicitly prohibiting PMD/PTE aliases w/
> different attributes although there are plenty of warnings and don'ts
> against giving different attributes to the same linear addresses.  At
> any rate, it definitely looks way too dangerous to depend on.

It is. We've had data corruption because of this in the past.
Worse it's very subtle data corruption, taking a long time
to track down. So yes it's definitely dangerous.
> 
> And, set_memory_*() is basically allowed on any memory allocated via
> get_free_page(), so... we're between rock and hard place.  Looks like

The x86-64 kernel has the text mapping alias which had similar problems.
That was avoided by special casing this.

> remapping partially using large pages is no go.

I'm not sure it was ever a good idea because most CPUs have much less
large TLB entries than small entries. 
(in some cases the difference is dramatic, a few older cores
only had something like 4 2/4MB entries) 
Unless it's really a lot of memory you're talking about here
it's probably better to use small pages for such specific
purposes.

The other issue is that with 1GB pages used in the direct mapping
the problem generally gets much worse. Although luckily it only
hits because there is some dumb kernel code which always forces
smaller pages for GB 0 and 4.

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/