Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760126AbcDEVAe (ORCPT ); Tue, 5 Apr 2016 17:00:34 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:39673 "EHLO imgpgp01.kl.imgtec.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759797AbcDEVAc (ORCPT ); Tue, 5 Apr 2016 17:00:32 -0400 X-PGP-Universal: processed; by imgpgp01.kl.imgtec.org on Tue, 05 Apr 2016 22:00:30 +0100 Date: Tue, 5 Apr 2016 22:00:29 +0100 From: James Hogan To: Kees Cook CC: Ralf Baechle , "kernel-hardening@lists.openwall.com" , Linux MIPS Mailing List , Matt Redfearn , "Aaro Koskinen" , Masahiro Yamada , Alexander Sverdlin , LKML , "Thomas Gleixner" , David Daney , Jaedon Shin , Jonas Gorski , "Paul Burton" Subject: Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR Message-ID: <20160405210029.GG31316@jhogan-linux.le.imgtec.org> References: <1459415142-3412-1-git-send-email-matt.redfearn@imgtec.com> <20160404233721.GB26295@linux-mips.org> <20160405090923.GF31316@jhogan-linux.le.imgtec.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7lMq7vMTJT4tNk0a" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [192.168.154.110] X-ESG-ENCRYPT-TAG: 38cac10 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3213 Lines: 73 --7lMq7vMTJT4tNk0a Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 05, 2016 at 11:10:40AM -0700, Kees Cook wrote: > On Tue, Apr 5, 2016 at 2:09 AM, James Hogan wrot= e: > > 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. >=20 > Ah, so it couldn't cover a 64-bit userspace range? Correct. 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) =2E.. 0x8000000000000000..0xbfffffffffffffff 8 64-bit unmapped segments (kern) =2E.. <- 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. Cheers James --7lMq7vMTJT4tNk0a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXBCdtAAoJEGwLaZPeOHZ6xEYP/1QCAip793JX3QvQlc34TXLt sORXtYXDhQdSUc0JcWuarMMdqaXaJXismSp8Hf8uGDlFQDnPubCoeSNi1Cuz5gLR aN5IjBYdlbUAKcxDzNnmuNmdrXwTiv90QIiqGzvE9TRY+j/06N4tVfAr6kRNew9l gZMHbozKa/abz3dr2+QeoivDAo21tCIaDgCxDnNiaBkvQ4UfPZ7X9nyRO72FCakx cyHIaEp+MkVe4r9hyFGUHEOkYTmQ4J2Dou80vjRNc9BpKgkE2sUMruR0+7iBtxXQ zl5l6HWbNSKI2ZtsQLej8ud7+8KFlDPQmIIArnf0eeFunrY8RRUVS2lsgHLMYqeK 3iwU4sOK3y59yaWC7p7RGspGpW28uu29OOdbEFMH/Ra2Xq5ChF/tahVGKvYCbJpg o6F5O/kNfA6ELKaQGkKURy9ukOWr3Jl8QkmeTbd1VMjsN54jiqSvZ5pTYXMb1m61 mKCy3IrNpHEZ+H74NWTAkoOyqN6npwCZO3i+I+wzDpcN4ug3ieCM40axm0BGV5WC nX59qkmtySxAgRw0yKmgABNd4Gqt4a9dHVGxcjWgSTSjw1Q/5NLZDvnXVXQEIDpl RyBZEFRMGxzR7HAvn6NFas6iETZIDMcvcqCjT7296hWwxpe7gAxMcQqMhgpzyjaF mdB1GgOr+yuNWfqDmu+B =d+Hw -----END PGP SIGNATURE----- --7lMq7vMTJT4tNk0a--