From patchwork Fri Jun 30 15:22:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 9819855 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C1E5A60224 for ; Fri, 30 Jun 2017 15:22:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B4CB52865A for ; Fri, 30 Jun 2017 15:22:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A958F2867C; Fri, 30 Jun 2017 15:22:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 84F962865A for ; Fri, 30 Jun 2017 15:22:35 +0000 (UTC) Received: (qmail 19590 invoked by uid 550); 30 Jun 2017 15:22:33 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 19564 invoked from network); 30 Jun 2017 15:22:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7Cnu3lLEiIq8ZPkCnQGqN+Bc0AefmHvulOELyR4WHwE=; b=JkxfoPrzYOakrB3c6WNkfYjaz/dscZEsVdT6WIkqS3BSF6XVdQci1oSaj2zkRpVO7a 7H1FclyNENK7BdYQIJqkN+qjuONsDozCxcrU9jHNalQcXqOuJk2HG6wzGlQENe2QVLMl zIjcPqonfnbq0z+mjQyRfwhARWLoIJyoFE3x4I8xdo2I2bRZyU/iYYt/LZrRjBASzaY3 /vCUikrPWVTdvZFMiHm5+LUF7DJXCX7RJAZ6v4AcZzvW3UJPLc905bYAtiF3td9cM58q 28oFqS4BFYQyHKSBmHEFixIVFhnJYLMFUQwm/CvoSo2NV93Nive4+awZHkp46C2yWGqO DWgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7Cnu3lLEiIq8ZPkCnQGqN+Bc0AefmHvulOELyR4WHwE=; b=GfuMWwEeUvyr2vCpkT1uXUb8vMXLtNyHCdx7g87/vmmygo07JmhtLR7/81BU2a+s9X HSWyklHDIuUS5FghqZWV0QwfVmDbNX0DbBFj+4eGNUf7fKbQngpLUvcGjQ0GcFkuZbSF rnSi3AOI8WcgmcMAqAHxvqf1aDO143PsdKQfX6xEO6icOXNcd6IfGK3AZe49ashjnz0F IujIO/+4MhqKkl0cVwS5LTJwdowa9NTj+oh4PVvax2Y0w4x3iwfBWKRCetE3MFy3nx8X GHQ2JQcbmqpneyopHsI0pGDqjI2NgcLjcyrXhWo6lZb0d29ETeQKA5XifUna14mDvsnu tvVA== X-Gm-Message-State: AKS2vOwfM0GTeeaeYG4Cz2GKeggs2frlQd6lsfkSEpDTW0Mrjq3nrUb4 y6KB2Pn9KxSbfT7mR+Hh7B8fGSVPcQ== X-Received: by 10.202.106.79 with SMTP id f76mr11472030oic.16.1498836140546; Fri, 30 Jun 2017 08:22:20 -0700 (PDT) MIME-Version: 1.0 Sender: arndbergmann@gmail.com In-Reply-To: References: <1495829844-69341-1-git-send-email-keescook@chromium.org> <1495829844-69341-5-git-send-email-keescook@chromium.org> From: Arnd Bergmann Date: Fri, 30 Jun 2017 17:22:19 +0200 X-Google-Sender-Auth: jKeSGndp93RBUZ65kWstVG2sCC4 Message-ID: To: Kees Cook Cc: Ard Biesheuvel , Kernel Hardening , Laura Abbott , "the arch/x86 maintainers" , Linux Kernel Mailing List , Russell King - ARM Linux , Nicolas Pitre , Will Deacon Subject: [kernel-hardening] Re: [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Jun 30, 2017 at 4:41 PM, Kees Cook wrote: > On Fri, Jun 30, 2017 at 1:27 AM, Arnd Bergmann wrote: >> On Fri, Jun 30, 2017 at 9:55 AM, Ard Biesheuvel >> wrote: >>> On 30 June 2017 at 07:35, Arnd Bergmann wrote: >>>> On Fri, Jun 30, 2017 at 12:53 AM, Kees Cook wrote: >>>>> The first obviously won't fly. The second just bypasses the problem >>>>> forcing it to be exposed by other people later. The third is likely >>>>> easiest to do now, but reduces the effectiveness of randomization for >>>>> architectures that don't have sensitive immediate values. The fourth >>>>> sounds not generally useful. The fifth may be unacceptable to arm >>>>> maintainers due to performance impacts. >>>> >>>> I was thinking of the fifth solution, but don't know exactly how to >>>> do it. If performance is a concern, I guess we could have separate >>>> implementations for randstruct and traditional builds. >>>> >>> >>> Does this not apply to *all* entries in asm-offsets? If so, I don't >>> see how it is tractable to fix this in the code, unless we add some >>> instrumentation to asm-offsets to whitelist some huge structs and >>> error out on new ones. Or perhaps there's really only a handful? >> >> I think the other structs are all small enough: >> >> * thread_info is at most 720 bytes (including crunch+vfp3, which >> you wouldn't find in one combined kernel) and not randomized >> at the moment >> * pt_regs is 72 bytes and I don't see how that would be randomized >> * machine_desc would be a candidate for randomizing, but is only >> 108 bytes >> * proc_info_list is 52 bytes and not currently randomized >> * vm_area_struct is randomized but only 96 bytes. >> * task_struct is clearly large enough, but we only use TSK_ACTIVE_MM >> and TSK_STACK_CANARY, both can be fixed with your trick. > > Yup, that matches what I found. task_struct is the only truly giant struct. > >>> In any case, these particular examples are fairly straightforward, >>> since there is no need to preserve the register's value. >>> >>> ldr r7, [r7, #TSK_STACK_CANARY] >>> >>> could be replaced with >>> >>> .if TSK_STACK_CANARAY >= PAGE_SIZE >>> add r7, r7, #TSK_STACK_CANARY & PAGE_MASK >>> .endif >>> ldr r7, [r7, #TSK_STACK_CANARY & ~PAGE_MASK] >> >> Nice! > > Oh, very cool. This'll make it only an asm change in the case where > it's required for randstruct. Perfect. I'll send a patch and carry it > in the randstruct tree. > > (In looking at this, it seems tsk_mm is unused in mm/proc-macros.S, so > I'll remove that code unless someone sees something I don't.) Ah, I missed that. This is what I have committed locally (sorry, doesn't apply because gmail). Note that I had to compare against PAGE_MASK here rather than PAGE_SIZE, which contains a 'ul' postfix that the assembler doesn't like. I'll send another copy to the list separately later today, once my randconfig builds complete (there have been some other regressions in the last few days, this one seems fine now). Arnd commit 3b6308404cd40edcff9f5e2aacd3cff9b67d660c Author: Arnd Bergmann Date: Fri Jun 30 13:50:23 2017 +0200 ARM: fix randomized task_struct With the new task struct randomization, we can run into a build failure for certain random seeds: arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:803: Error: bad immediate value for offset (4096) Only two constants in asm-offset.h are affected, and I'm changing both of them here to work correctly in all configurations. Suggested-by: Ard Biesheuvel Fixes: c33d8b12fbbd ("task_struct: Allow randomized layout") Signed-off-by: Arnd Bergmann diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 9f157e7c51e7..db6d22b23bd8 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -797,7 +797,10 @@ ENTRY(__switch_to) #if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP) ldr r7, [r2, #TI_TASK] ldr r8, =__stack_chk_guard - ldr r7, [r7, #TSK_STACK_CANARY] + .if (TSK_STACK_CANARY > PAGE_MASK) + add r7, r7, #TSK_STACK_CANARY & PAGE_MASK + .endif + ldr r7, [r7, #TSK_STACK_CANARY & ~PAGE_MASK] #endif #ifdef CONFIG_CPU_USE_DOMAINS mcr p15, 0, r6, c3, c0, 0 @ Set domain register diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S index 0d40c285bd86..c7bd8fcf16a7 100644 --- a/arch/arm/mm/proc-macros.S +++ b/arch/arm/mm/proc-macros.S @@ -37,7 +37,10 @@ bic \rd, sp, #8128 bic \rd, \rd, #63 ldr \rd, [\rd, #TI_TASK] - ldr \rd, [\rd, #TSK_ACTIVE_MM] + .if (TSK_ACTIVE_MM > PAGE_MASK) + add \rd, \rd, #TSK_ACTIVE_MM & PAGE_MASK + .endif + ldr \rd, [\rd, #TSK_ACTIVE_MM & ~PAGE_MASK] .endm /*