From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EA57F133B for ; Tue, 1 Sep 2015 16:53:00 +0000 (UTC) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 65BC8261 for ; Tue, 1 Sep 2015 16:53:00 +0000 (UTC) Received: by ioii196 with SMTP id i196so8139813ioi.3 for ; Tue, 01 Sep 2015 09:52:59 -0700 (PDT) MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: References: <1440446941.2201.32.camel@HansenPartnership.com> <87h9nf9nv5.fsf@x220.int.ebiederm.org> Date: Tue, 1 Sep 2015 09:52:59 -0700 Message-ID: From: Kees Cook To: Jiri Kosina Content-Type: text/plain; charset=UTF-8 Cc: James Bottomley , "ksummit-discuss@lists.linuxfoundation.org" , Emily Ratliff Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Sep 1, 2015 at 2:03 AM, Jiri Kosina wrote: > On Mon, 31 Aug 2015, Eric W. Biederman wrote: > >> At the same time I think we to serious consider tossing attempts that >> fails to close a class of exploits. >> >> The kernel address space randomization on x86_64 I find disturbing. We >> have a 2GB address space for kernel code. We have pages that are 2MB in >> that address space. So we only have 10 bits that can change. Only 9 >> bits that can change if the kernel needs more than one 2MB page. Which >> means that at most we need to brute force 1024 things to exploit any >> weakness. > > I understand what you are saying. OTOH, assuming that kernel doesn't leak > addressess when restrict_kptr is set, it's rather likely that bruteforcing > attempt to exploit the kernel is going to crash it instead of privilege > escalation happenin (because the address wouldn't match, and either the > kernel will #GP directly, or do some totally random garbage and crash > shortly afterwards). > > It's still *pretty* bad, but arguably better than being silently > compromised without anyone noticing. This reminds me: we must assume all users on a system (and all devices being attached) have access to a write-anywhere primitive (since they DO -- we just haven't found them all yet, and we never will), what can we do to close the windows of exploitability? (e.g. making memory read-only, adding CFI to defend against ROP via the stack, etc?) -Kees -- Kees Cook Chrome OS Security