Date: Wed, 6 Jul 2016 15:25:19 -0700 From: Kees Cook <keescook@...omium.org> To: linux-kernel@...r.kernel.org Cc: Kees Cook <keescook@...omium.org>, Rik van Riel <riel@...hat.com>, Casey Schaufler <casey@...aufler-ca.com>, PaX Team <pageexec@...email.hu>, Brad Spengler <spender@...ecurity.net>, Russell King <linux@...linux.org.uk>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Michael Ellerman <mpe@...erman.id.au>, Tony Luck <tony.luck@...el.com>, Fenghua Yu <fenghua.yu@...el.com>, "David S. Miller" <davem@...emloft.net>, x86@...nel.org, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton <akpm@...ux-foundation.org>, Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...e.de>, Mathias Krause <minipli@...glemail.com>, Jan Kara <jack@...e.cz>, Vitaly Wool <vitalywool@...il.com>, Andrea Arcangeli <aarcange@...hat.com>, Dmitry Vyukov <dvyukov@...gle.com>, Laura Abbott <labbott@...oraproject.org>, linux-arm-kernel@...ts.infradead.org, linux-ia64@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org, linux-arch@...r.kernel.org, linux-mm@...ck.org, kernel-hardening@...ts.openwall.com Subject: [PATCH 0/9] mm: Hardened usercopy Hi, This is a start of the mainline port of PAX_USERCOPY. After I started writing tests (now in lkdtm in -next) for Casey's earlier port, I kept tweaking things further and further until I ended up with a whole new patch series. To that end, I took Rik's feedback and made a number of other changes and clean-ups as well. Based on my understanding, PAX_USERCOPY was designed to catch a few classes of flaws around the use of copy_to_user()/copy_from_user(). These changes don't touch get_user() and put_user(), since these operate on constant sized lengths, and tend to be much less vulnerable. There are effectively three distinct protections in the whole series, each of which I've given a separate CONFIG, though this patch set is only the first of the three intended protections. (Generally speaking, PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS covers CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).) This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects being copied to/from userspace meet certain criteria: - if address is a heap object, the size must not exceed the object's allocated size. (This will catch all kinds of heap overflow flaws.) - if address range is in the current process stack, it must be within the current stack frame (if such checking is possible) or at least entirely within the current process's stack. (This could catch large lengths that would have extended beyond the current process stack, or overflows if their length extends back into the original stack.) - if the address range is part of kernel data, rodata, or bss, allow it. - if address range is page-allocated, that it doesn't span multiple allocations. - if address is within the kernel text, reject it. - everything else is accepted The patches in the series are: - The core copy_to/from_user() checks, without the slab object checks: 1- mm: Hardened usercopy - Per-arch enablement of the protection: 2- x86/uaccess: Enable hardened usercopy 3- ARM: uaccess: Enable hardened usercopy 4- arm64/uaccess: Enable hardened usercopy 5- ia64/uaccess: Enable hardened usercopy 6- powerpc/uaccess: Enable hardened usercopy 7- sparc/uaccess: Enable hardened usercopy - The heap allocator implementation of object size checking: 8- mm: SLAB hardened usercopy support 9- mm: SLUB hardened usercopy support Some notes: - This is expected to apply on top of -next which contains fixes for the position of _etext on both arm and arm64. - I couldn't detect a measurable performance change with these features enabled. Kernel build times were unchanged, hackbench was unchanged, etc. I think we could flip this to "on by default" at some point. - The SLOB support extracted from grsecurity seems entirely broken. I have no idea what's going on there, I spent my time testing SLAB and SLUB. Having someone else look at SLOB would be nice, but this series doesn't depend on it. Additional features that would be nice, but aren't blocking this series: - Needs more architecture support for stack frame checking (only x86 now). Thanks! -Kees  https://grsecurity.net/download.php "grsecurity - test kernel patch"  http://www.openwall.com/lists/kernel-hardening/2016/05/19/5
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.