From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754111AbdC2TOt (ORCPT ); Wed, 29 Mar 2017 15:14:49 -0400 Received: from mail-it0-f44.google.com ([209.85.214.44]:37256 "EHLO mail-it0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752592AbdC2TOs (ORCPT ); Wed, 29 Mar 2017 15:14:48 -0400 MIME-Version: 1.0 In-Reply-To: <20170329190008.GE7909@n2100.armlinux.org.uk> References: <1490811363-93944-1-git-send-email-keescook@chromium.org> <20170329190008.GE7909@n2100.armlinux.org.uk> From: Kees Cook Date: Wed, 29 Mar 2017 12:14:45 -0700 X-Google-Sender-Auth: cYAzwRp3GQ0fOszufgpoXVaOc5k Message-ID: Subject: Re: [RFC v2] Introduce rare_write() infrastructure To: Russell King - ARM Linux Cc: "kernel-hardening@lists.openwall.com" , Mark Rutland , Andy Lutomirski , Hoeun Ryu , PaX Team , Emese Revfy , "x86@kernel.org" , LKML , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 29, 2017 at 12:00 PM, Russell King - ARM Linux wrote: > On Wed, Mar 29, 2017 at 11:15:52AM -0700, Kees Cook wrote: >> This is take 2 of an RFC series to demonstrate a possible infrastructure >> for the "write rarely" memory storage type in the kernel (patch 1). The >> intent is to further reduce the internal attack surface of the kernel >> by making more variables read-only while "at rest". This is heavily >> based on the "__read_only" portion of the KERNEXEC infrastructure from >> PaX/grsecurity, though I tried to adjust it to be more in line with >> the upstream discussions around the APIs. > > How much data are we talking about here? The goal is to put as much sensitive stuff from .data as possible into .rodata, which is mostly structures with function pointers, etc. I haven't measured the "final" results, since there's still a lot of work to do to get all the other annotations into upstream. >> As part of the series I've included both x86 support (patch 4), exactly >> as done in PaX, and ARM support (patches 5-7), similar to what is done in >> grsecurity but without support for earlier ARM CPUs. Both are lightly >> tested by me, though they need a bit more work, especially ARM as it is >> missing the correct domain marking for kernel modules. > > The implementation as it stands on ARM is going to gobble up > multiples of 1MB of RAM as you need it to be section aligned due to > using domains, so if we're talking about a small amount of data, > this is very inefficient. That also only works for non-LPAE as LPAE > is unable to use that method. AIUI, we're just flipping toe domain from DOMAIN_KERNEL to DOMAIN_WR_RARE on the .rodata section (which is already 1MB aligned), and (in the future if I or someone else can figure out how) on the kernel module vmap area (which also shouldn't be changing alignment at all). -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Wed, 29 Mar 2017 12:14:45 -0700 Subject: [RFC v2] Introduce rare_write() infrastructure In-Reply-To: <20170329190008.GE7909@n2100.armlinux.org.uk> References: <1490811363-93944-1-git-send-email-keescook@chromium.org> <20170329190008.GE7909@n2100.armlinux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Mar 29, 2017 at 12:00 PM, Russell King - ARM Linux wrote: > On Wed, Mar 29, 2017 at 11:15:52AM -0700, Kees Cook wrote: >> This is take 2 of an RFC series to demonstrate a possible infrastructure >> for the "write rarely" memory storage type in the kernel (patch 1). The >> intent is to further reduce the internal attack surface of the kernel >> by making more variables read-only while "at rest". This is heavily >> based on the "__read_only" portion of the KERNEXEC infrastructure from >> PaX/grsecurity, though I tried to adjust it to be more in line with >> the upstream discussions around the APIs. > > How much data are we talking about here? The goal is to put as much sensitive stuff from .data as possible into .rodata, which is mostly structures with function pointers, etc. I haven't measured the "final" results, since there's still a lot of work to do to get all the other annotations into upstream. >> As part of the series I've included both x86 support (patch 4), exactly >> as done in PaX, and ARM support (patches 5-7), similar to what is done in >> grsecurity but without support for earlier ARM CPUs. Both are lightly >> tested by me, though they need a bit more work, especially ARM as it is >> missing the correct domain marking for kernel modules. > > The implementation as it stands on ARM is going to gobble up > multiples of 1MB of RAM as you need it to be section aligned due to > using domains, so if we're talking about a small amount of data, > this is very inefficient. That also only works for non-LPAE as LPAE > is unable to use that method. AIUI, we're just flipping toe domain from DOMAIN_KERNEL to DOMAIN_WR_RARE on the .rodata section (which is already 1MB aligned), and (in the future if I or someone else can figure out how) on the kernel module vmap area (which also shouldn't be changing alignment at all). -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <20170329190008.GE7909@n2100.armlinux.org.uk> References: <1490811363-93944-1-git-send-email-keescook@chromium.org> <20170329190008.GE7909@n2100.armlinux.org.uk> From: Kees Cook Date: Wed, 29 Mar 2017 12:14:45 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [kernel-hardening] Re: [RFC v2] Introduce rare_write() infrastructure To: Russell King - ARM Linux Cc: "kernel-hardening@lists.openwall.com" , Mark Rutland , Andy Lutomirski , Hoeun Ryu , PaX Team , Emese Revfy , "x86@kernel.org" , LKML , "linux-arm-kernel@lists.infradead.org" List-ID: On Wed, Mar 29, 2017 at 12:00 PM, Russell King - ARM Linux wrote: > On Wed, Mar 29, 2017 at 11:15:52AM -0700, Kees Cook wrote: >> This is take 2 of an RFC series to demonstrate a possible infrastructure >> for the "write rarely" memory storage type in the kernel (patch 1). The >> intent is to further reduce the internal attack surface of the kernel >> by making more variables read-only while "at rest". This is heavily >> based on the "__read_only" portion of the KERNEXEC infrastructure from >> PaX/grsecurity, though I tried to adjust it to be more in line with >> the upstream discussions around the APIs. > > How much data are we talking about here? The goal is to put as much sensitive stuff from .data as possible into .rodata, which is mostly structures with function pointers, etc. I haven't measured the "final" results, since there's still a lot of work to do to get all the other annotations into upstream. >> As part of the series I've included both x86 support (patch 4), exactly >> as done in PaX, and ARM support (patches 5-7), similar to what is done in >> grsecurity but without support for earlier ARM CPUs. Both are lightly >> tested by me, though they need a bit more work, especially ARM as it is >> missing the correct domain marking for kernel modules. > > The implementation as it stands on ARM is going to gobble up > multiples of 1MB of RAM as you need it to be section aligned due to > using domains, so if we're talking about a small amount of data, > this is very inefficient. That also only works for non-LPAE as LPAE > is unable to use that method. AIUI, we're just flipping toe domain from DOMAIN_KERNEL to DOMAIN_WR_RARE on the .rodata section (which is already 1MB aligned), and (in the future if I or someone else can figure out how) on the kernel module vmap area (which also shouldn't be changing alignment at all). -Kees -- Kees Cook Pixel Security