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 EBC7A71 for ; Thu, 4 Aug 2016 05:54:59 +0000 (UTC) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E6D419E for ; Thu, 4 Aug 2016 05:54:59 +0000 (UTC) Received: by mail-wm0-f50.google.com with SMTP id o80so363932301wme.1 for ; Wed, 03 Aug 2016 22:54:59 -0700 (PDT) MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: References: <3aa8df3e-3705-9fd5-640c-37c0be2af561@imgtec.com> <0E98DCC5-01EE-4FA7-B6D4-72772279BDFF@arm.com> From: Kees Cook Date: Wed, 3 Aug 2016 22:54:49 -0700 Message-ID: To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Cc: Dave Hansen , "ksummit-discuss@lists.linuxfoundation.org" , Jann Horn Subject: Re: [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Aug 3, 2016 at 10:45 PM, Andy Lutomirski wrote: > On Wed, Aug 3, 2016 at 10:32 PM, Kees Cook wrote: >> On Wed, Aug 3, 2016 at 3:53 PM, Catalin Marinas wrote: >>> On 1 Aug 2016, at 00:05, Kees Cook wrote: >>>> On Sun, Jul 31, 2016 at 2:55 AM, Paul Burton wrote: >>>>> It would be very interesting to discuss what's needed from arch code for >>>>> various hardening features, both those currently in mainline & those in >>>>> development. >>> >>> I'm interested in such topic as well, primarily from an arm/arm64 perspective. >>> >>>> - Handling userspace/kernelspace memory segregation. (This is the SMAP >>>> of x86, PAN of ARM, and just native on s390.) For architectures (or >>>> chipsets within an architecture) that don't support unprivileged >>>> memory access restrictions in hardware, we must find a way to emulate >>>> it. (e.g. 32-bit ARM uses Domains, and 64-bit x86 could use PCIDs, >>>> etc.) Keeping these regions separate is extremely important in >>>> stopping exploitation. >>> >>> For arm64 ARMv8.0 (without hardware PAN), I'm going to post a patch >>> in a week or so which emulates PAN by switching the user page table (TTBR0) >>> to the zero page. I guess a similar approach could work for other architectures, >>> maybe using swapper_pg_dir as the PAN page table. >> >> At least on x86 I've heard grumblings that it can be prohibitively >> expensive due to TLB-flushing, but I'd still like to see an >> implementation doing it first. :) > > No TLB flush needed if we use PCID. Linus will attack you with a > pitchfork either way, though :) Hmm, my asbestos suit won't help me there. I will need to invest in titanium. :) The TLB flushing way I can understand being pitchfork-worthy, though I'm curious why a PCID implementation would be upsetting? > It shouldn't be *that* hard to build this thing on top of my PCID > patchset. I need to dust that off, which I'll do right after vmap > stacks land and I finish fsgsbase. Sigh, so many things. What does your PCID series do? -Kees -- Kees Cook Brillo & Chrome OS Security