linux-kernel - Re: [PATCH v2] arm64: add alignment fault hanling

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 Feb 2016 10:50:02 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Will Deacon <will.deacon@....com>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Robin Murphy <robin.murphy@....com>,
	EunTaik Lee <eun.taik.lee@...sung.com>,
	"vladimir.murzin@....com" <vladimir.murzin@....com>,
	"suzuki.poulose@....com" <suzuki.poulose@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"salyzyn@...roid.com" <salyzyn@...roid.com>,
	"riandrews@...roid.com" <riandrews@...roid.com>,
	"james.morse@....com" <james.morse@....com>,
	"Dave.Martin@....com" <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Peter Anvin <hpa@...or.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2] arm64: add alignment fault hanling

On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon <will.deacon@....com> wrote:
> [replying to self and adding some x86 people]
>
> Background: Euntaik reports a problem where userspace has ended up with
> a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
> PCI memory bar from someplace in /sys). strncpy_from_user happens with
> the word-at-a-time implementation, and we end up reading into the MMIO
> page.
>
> Question: Does x86 guarantee that this faults? (Arjan reckoned no, but
> wasn't 100%).

x86 not only does *not* guarantee that that faults, but quite the
reverse: I'm pretty sure it would be considered an architectural bug
if it didn't silently "just work". IOW, the page-crossing unaligned
access will be split up as two accesses, and done as a regular cached
read for the normal RAM page part, and as an uncached IO read for the
MMIO page.

So if somebody passes us a string adjacent to a MMIO mapping, we'll
happily do the access on x86 and touch the MMIO space. No biggie, and
nobody sane actually does that. If you have the rights to do device
mappings, you should probably restrain from doing insane things. "With
great power comes great responsibility".

> Thinking more about this, we could spit out a guard page between every
> VMA, but it's likely to hamper any VMA merging.

More importantly, it wouldn't work for the general case. People often
pass in a specific virtual memory address to mmap because they *need*
adjacent mappings. One example of that case is doing a circular buffer
that is guaranteed to always be accessible linearly (and avoiding the
split case where it hits the end of the circular buffer) by mapping
the same buffer twice.

Of course, no actual real program will do that for mixing MMIO and
non-MMIO, and so we might obviously add code to always add a guard
page for the normal case when a specific address isn't asked for. So
as a heuristic to make sure it doesn't happen by mistake it possibly
makes sense.

You'd still want to make sure that you don't get a kernel oops if some
attacker tries to break ARM64 on purpose, obviously (although even
that is not necessarily a huge deal for somebody who already has
physical IO privileges). So I suspect that Eun Taik Lee's patch makes
perfect sense even if it's not necessarily the full solution in
itself.

                Linus