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 5FD1F413 for ; Thu, 4 Aug 2016 05:45:59 +0000 (UTC) Received: from mail-ua0-f176.google.com (mail-ua0-f176.google.com [209.85.217.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B908619E for ; Thu, 4 Aug 2016 05:45:58 +0000 (UTC) Received: by mail-ua0-f176.google.com with SMTP id 35so167993720uap.1 for ; Wed, 03 Aug 2016 22:45:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <3aa8df3e-3705-9fd5-640c-37c0be2af561@imgtec.com> <0E98DCC5-01EE-4FA7-B6D4-72772279BDFF@arm.com> From: Andy Lutomirski Date: Wed, 3 Aug 2016 22:45:37 -0700 Message-ID: To: Kees Cook 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: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 :) 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.