Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750899AbeAOUGW (ORCPT + 1 other); Mon, 15 Jan 2018 15:06:22 -0500 Received: from mail-ua0-f195.google.com ([209.85.217.195]:43746 "EHLO mail-ua0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750892AbeAOUGT (ORCPT ); Mon, 15 Jan 2018 15:06:19 -0500 X-Google-Smtp-Source: ACJfBosaOdjbLjAgVgy9V+3mmhZaxuOBox7Yb7JKKwkV71FqxP+m+AmqMxE/ES4U+ZIm0MLY4hfN4QqQUpVBeFD4yqQ= MIME-Version: 1.0 In-Reply-To: <20180115122458.GI12608@e103592.cambridge.arm.com> References: <1515636190-24061-1-git-send-email-keescook@chromium.org> <1515636190-24061-34-git-send-email-keescook@chromium.org> <20180115122458.GI12608@e103592.cambridge.arm.com> From: Kees Cook Date: Mon, 15 Jan 2018 12:06:17 -0800 X-Google-Sender-Auth: RGgJc4X1htTUWuYyxOe6UETvMEg Message-ID: Subject: Re: [PATCH 33/38] arm64: Implement thread_struct whitelist for hardened usercopy To: Dave P Martin Cc: "linux-kernel@vger.kernel.org" , Catalin Marinas , Will Deacon , Christian Borntraeger , Ingo Molnar , James Morse , "Peter Zijlstra (Intel)" , zijun_hu , "linux-arm-kernel@lists.infradead.org" , Linus Torvalds , David Windsor , Alexander Viro , Andrew Morton , Andy Lutomirski , Christoph Hellwig , Christoph Lameter , "David S. Miller" , Laura Abbott , Mark Rutland , "Martin K. Petersen" , Paolo Bonzini , Christoffer Dall , Dave Kleikamp , Jan Kara , Luis de Bethencourt , Marc Zyngier , Rik van Riel , Matthew Garrett , "linux-fsdevel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-mm@kvack.org" , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, Jan 15, 2018 at 4:24 AM, Dave P Martin wrote: > On Thu, Jan 11, 2018 at 02:03:05AM +0000, Kees Cook wrote: >> This whitelists the FPU register state portion of the thread_struct for >> copying to userspace, instead of the default entire structure. >> >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Christian Borntraeger >> Cc: Ingo Molnar >> Cc: James Morse >> Cc: "Peter Zijlstra (Intel)" >> Cc: Dave Martin >> Cc: zijun_hu >> Cc: linux-arm-kernel@lists.infradead.org >> Signed-off-by: Kees Cook >> --- >> arch/arm64/Kconfig | 1 + >> arch/arm64/include/asm/processor.h | 8 ++++++++ >> 2 files changed, 9 insertions(+) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index a93339f5178f..c84477e6a884 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -90,6 +90,7 @@ config ARM64 >> select HAVE_ARCH_MMAP_RND_BITS >> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT >> select HAVE_ARCH_SECCOMP_FILTER >> + select HAVE_ARCH_THREAD_STRUCT_WHITELIST >> select HAVE_ARCH_TRACEHOOK >> select HAVE_ARCH_TRANSPARENT_HUGEPAGE >> select HAVE_ARCH_VMAP_STACK >> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h >> index 023cacb946c3..e58a5864ec89 100644 >> --- a/arch/arm64/include/asm/processor.h >> +++ b/arch/arm64/include/asm/processor.h >> @@ -113,6 +113,14 @@ struct thread_struct { >> struct debug_info debug; /* debugging */ >> }; >> >> +/* Whitelist the fpsimd_state for copying to userspace. */ >> +static inline void arch_thread_struct_whitelist(unsigned long *offset, >> + unsigned long *size) >> +{ >> + *offset = offsetof(struct thread_struct, fpsimd_state); >> + *size = sizeof(struct fpsimd_state); > > This should be fpsimd_state.user_fpsimd (fpsimd_state.cpu is important > for correctly context switching and not supposed to be user-accessible. > A user copy that encompasses that is definitely a bug). So, I actually spent some more time looking at this due to the comments from rmk on arm32, and I don't think any whitelist is needed here at all. (i.e. it can be *offset = *size = 0) This is because all the usercopying I could find uses static sizes or bounce buffers, both of which bypass the dynamic-size hardened usercopy checks. I've been running some arm64 builds now with this change, and I haven't tripped over any problems yet... -Kees -- Kees Cook Pixel Security