linux-kernel - Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR

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] [day] [month] [year] [list]

Message-ID: <20160405210029.GG31316@jhogan-linux.le.imgtec.org>
Date:	Tue, 5 Apr 2016 22:00:29 +0100
From:	James Hogan <james.hogan@...tec.com>
To:	Kees Cook <keescook@...omium.org>
CC:	Ralf Baechle <ralf@...ux-mips.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
	Matt Redfearn <matt.redfearn@...tec.com>,
	"Aaro Koskinen" <aaro.koskinen@...ia.com>,
	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Alexander Sverdlin <alexander.sverdlin@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	David Daney <ddaney@...iumnetworks.com>,
	Jaedon Shin <jaedon.shin@...il.com>,
	Jonas Gorski <jogo@...nwrt.org>,
	"Paul Burton" <paul.burton@...tec.com>
Subject: Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel &
 KASLR

On Tue, Apr 05, 2016 at 11:10:40AM -0700, Kees Cook wrote:
> On Tue, Apr 5, 2016 at 2:09 AM, James Hogan <james.hogan@...tec.com> wrote:
> > EVA (enhanced virtual addressing) is a feature present on recent MIPS
> > 32-bit i-class and p-class cores (and p6600 too which is 64-bit),
> > intended to make better use of 32-bit virtual address space. It can
> > actually overlap kernel and virtual address space, requiring special
> > instructions for accessing userland mappings, however each segment can't
> > have distinct TLB mappings for kernel and user mode (if kernel and user
> > view of segment differs, kernel would need to see it unmapped, i.e. a
> > window into physical memory). As such its generally better to keep the
> > lowest segment visible to both kernel and user, so that kernel NULL
> > dereferences can still be caught, which would negate the point of using
> > it for security. It is possible to make it work with watchpoints to
> > catch NULL dereferences in lowest 4KB, so kernel can't access any user
> > address space directly, but thats a bit of a hack really. Also since EVA
> > is aimed at making better use of 32-bit address space, it doesn't
> > address 64-bit.
> 
> Ah, so it couldn't cover a 64-bit userspace range?

Correct.

<long version>
OTOH the segments that can be configured by EVA on MIPS64 (specifically
P6600 core) are:

0xffffffffe0000000..0xffffffffffffffff 512MB (normally kernel mapped)
0xffffffffc0000000..0xffffffffdfffffff 512MB (normally kernel mapped)
0xffffffffa0000000..0xffffffffbfffffff 512MB (normally kernel uncached)
0xffffffff80000000..0xffffffff9fffffff 512MB (normally kernel)
...
0x8000000000000000..0xbfffffffffffffff 8 64-bit unmapped segments (kern)
... <- MIPS64 extends user address space here
0x0000000040000000..0x000000007fffffff 1GB (normally user)
0x0000000000000000..0x000000003fffffff 1GB (normally user)

In the middle there, MIPS64 extends userspace from 0x0000000080000000
towards 0x4000000000000000 (depending on number of virtual address bits
implemented), over which there is no segmentation control.
</long version>

Cheers
James

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)