diff for duplicates of <1468830403.2800.0.camel@gmail.com> diff --git a/a/1.txt b/N1/1.txt index 9684118..dfa3d88 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -97,4 +97,8 @@ On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote: Thanks looks good so far! I'll try and test it and report back -Balbir +Balbir +-- +To unsubscribe from this list: send the line "unsubscribe linux-ia64" in +the body of a message to majordomo@vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index a72c3eb..1b4e6db 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,6 +1,6 @@ "ref\01468619065-3222-1-git-send-email-keescook@chromium.org\0" "From\0Balbir Singh <bsingharora@gmail.com>\0" - "Subject\0[kernel-hardening] Re: [PATCH v3 00/11] mm: Hardened usercopy\0" + "Subject\0Re: [PATCH v3 00/11] mm: Hardened usercopy\0" "Date\0Mon, 18 Jul 2016 18:26:43 +1000\0" "To\0Kees Cook <keescook@chromium.org>" " linux-kernel@vger.kernel.org\0" @@ -27,19 +27,7 @@ Andrew Morton <akpm@linux-foundation.org> Andy Lutomirski <luto@kernel.org> Borislav Petkov <bp@suse.de> - Mathias Krause <minipli@googlemail.com> - Jan Kara <jack@suse.cz> - Vitaly Wool <vitalywool@gmail.com> - Andrea Arcangeli <aarcange@redhat.com> - Dmitry Vyukov <dvyukov@google.com> - Laura Abbott <labbott@fedoraproject.org> - linux-arm-kernel@lists.infradead.org - linux-ia64@vger.kernel.org - linuxppc-dev@lists.ozlabs.org - sparclinux@vger.kernel.org - linux-arch@vger.kernel.org - linux-mm@kvack.org - " kernel-hardening@lists.openwall.com\0" + " Mathias Krause <minipli>\0" "\00:1\0" "b\0" "On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote:\n" @@ -141,6 +129,10 @@ "\n" "Thanks looks good so far! I'll try and test it and report back\n" "\n" - Balbir + "Balbir\302\240\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-ia64\" in\n" + "the body of a message to majordomo@vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -e9a5f4acf13b4d5551096ae398377be350365f5d19dd16aea95c0f7a00d57642 +e85b9ee10be7e6f03f2c13c3759bb765b2c0818dcd5f5b7dfe27f9833a0fd3d8
diff --git a/a/content_digest b/N2/content_digest index a72c3eb..5472b65 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,6 +1,6 @@ "ref\01468619065-3222-1-git-send-email-keescook@chromium.org\0" "From\0Balbir Singh <bsingharora@gmail.com>\0" - "Subject\0[kernel-hardening] Re: [PATCH v3 00/11] mm: Hardened usercopy\0" + "Subject\0Re: [PATCH v3 00/11] mm: Hardened usercopy\0" "Date\0Mon, 18 Jul 2016 18:26:43 +1000\0" "To\0Kees Cook <keescook@chromium.org>" " linux-kernel@vger.kernel.org\0" @@ -143,4 +143,4 @@ "\n" Balbir -e9a5f4acf13b4d5551096ae398377be350365f5d19dd16aea95c0f7a00d57642 +5ea7dcaeac853285111537b79f87499af3d1d049601496920180d8a3e5aa4e1f
diff --git a/a/content_digest b/N3/content_digest index a72c3eb..784741a 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -1,7 +1,7 @@ "ref\01468619065-3222-1-git-send-email-keescook@chromium.org\0" "From\0Balbir Singh <bsingharora@gmail.com>\0" - "Subject\0[kernel-hardening] Re: [PATCH v3 00/11] mm: Hardened usercopy\0" - "Date\0Mon, 18 Jul 2016 18:26:43 +1000\0" + "Subject\0Re: [PATCH v3 00/11] mm: Hardened usercopy\0" + "Date\0Mon, 18 Jul 2016 08:26:43 +0000\0" "To\0Kees Cook <keescook@chromium.org>" " linux-kernel@vger.kernel.org\0" "Cc\0Daniel Micay <danielmicay@gmail.com>" @@ -143,4 +143,4 @@ "\n" Balbir -e9a5f4acf13b4d5551096ae398377be350365f5d19dd16aea95c0f7a00d57642 +2b0dcbe1d88a8c8f9ec8da23498b4836ab82842f6c064d257bba8e32b8c80382
diff --git a/a/1.txt b/N4/1.txt index 9684118..f91646d 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -1,17 +1,17 @@ On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote: > Hi, -> +>? > [I'm going to carry this series in my kspp -next tree now, though I'd > really love to have some explicit Acked-bys or Reviewed-bys. If you've > looked through it or tested it, please consider it. :) (I added Valdis > and mpe's Tested-bys where they seemed correct, thank you!)] -> +>? > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I kept > tweaking things further and further until I ended up with a whole new > patch series. To that end, I took Rik and other people's feedback along > with other changes and clean-ups. -> +>? > Based on my understanding, PAX_USERCOPY was designed to catch a > few classes of flaws (mainly bad bounds checking) around the use of > copy_to_user()/copy_from_user(). These changes don't touch get_user() and @@ -23,72 +23,72 @@ On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote: > (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.) +> ? 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.) +> ? 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. +> ? allocations. > - if address is within the kernel text, reject it. > - everything else is accepted -> +>? > The patches in the series are: > - Support for arch-specific stack frame checking (which will likely be -> replaced in the future by Josh's more comprehensive unwinder): -> 1- mm: Implement stack frame object validation +> ? replaced in the future by Josh's more comprehensive unwinder): +> ????????1- mm: Implement stack frame object validation > - The core copy_to/from_user() checks, without the slab object checks: -> 2- mm: Hardened usercopy +> ????????2- mm: Hardened usercopy > - Per-arch enablement of the protection: -> 3- x86/uaccess: Enable hardened usercopy -> 4- ARM: uaccess: Enable hardened usercopy -> 5- arm64/uaccess: Enable hardened usercopy -> 6- ia64/uaccess: Enable hardened usercopy -> 7- powerpc/uaccess: Enable hardened usercopy -> 8- sparc/uaccess: Enable hardened usercopy -> 9- s390/uaccess: Enable hardened usercopy +> ????????3- x86/uaccess: Enable hardened usercopy +> ????????4- ARM: uaccess: Enable hardened usercopy +> ????????5- arm64/uaccess: Enable hardened usercopy +> ????????6- ia64/uaccess: Enable hardened usercopy +> ????????7- powerpc/uaccess: Enable hardened usercopy +> ????????8- sparc/uaccess: Enable hardened usercopy +> ????????9- s390/uaccess: Enable hardened usercopy > - The heap allocator implementation of object size checking: -> 10- mm: SLAB hardened usercopy support -> 11- mm: SLUB hardened usercopy support -> +> ???????10- mm: SLAB hardened usercopy support +> ???????11- 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, though it has minor conflicts -> with KASAN that are trivial to fix up. Living in -next are also tests -> for this protection in lkdtm, prefixed with USERCOPY_. -> +> ? position of _etext on both arm and arm64, though it has minor conflicts +> ? with KASAN that are trivial to fix up. Living in -next are also tests +> ? for this protection in lkdtm, prefixed with USERCOPY_. +>? > - 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, but -> for now, I'm leaving it off until I can get some more definitive -> measurements. I would love if someone with greater familiarity with -> perf could give this a spin and report results. -> +> ? enabled. Kernel build times were unchanged, hackbench was unchanged, +> ? etc. I think we could flip this to "on by default" at some point, but +> ? for now, I'm leaving it off until I can get some more definitive +> ? measurements. I would love if someone with greater familiarity with +> ? perf could give this a spin and report results. +>? > - 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. -> +> ? 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, -> but it seems Josh will have a good solution for this soon). -> -> +> ? but it seems Josh will have a good solution for this soon). +>? +>? > Thanks! -> +>? > -Kees -> +>? > [1] https://grsecurity.net/download.php "grsecurity - test kernel patch" > [2] http://www.openwall.com/lists/kernel-hardening/2016/05/19/5 -> +>? > v3: > - switch to using BUG for better Oops integration > - when checking page allocations, check each for Reserved @@ -97,4 +97,4 @@ On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote: Thanks looks good so far! I'll try and test it and report back -Balbir +Balbir? diff --git a/a/content_digest b/N4/content_digest index a72c3eb..284e1ea 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -1,61 +1,24 @@ "ref\01468619065-3222-1-git-send-email-keescook@chromium.org\0" - "From\0Balbir Singh <bsingharora@gmail.com>\0" - "Subject\0[kernel-hardening] Re: [PATCH v3 00/11] mm: Hardened usercopy\0" + "From\0bsingharora@gmail.com (Balbir Singh)\0" + "Subject\0[PATCH v3 00/11] mm: Hardened usercopy\0" "Date\0Mon, 18 Jul 2016 18:26:43 +1000\0" - "To\0Kees Cook <keescook@chromium.org>" - " linux-kernel@vger.kernel.org\0" - "Cc\0Daniel Micay <danielmicay@gmail.com>" - Josh Poimboeuf <jpoimboe@redhat.com> - Rik van Riel <riel@redhat.com> - Casey Schaufler <casey@schaufler-ca.com> - PaX Team <pageexec@freemail.hu> - Brad Spengler <spender@grsecurity.net> - Russell King <linux@armlinux.org.uk> - Catalin Marinas <catalin.marinas@arm.com> - Will Deacon <will.deacon@arm.com> - Ard Biesheuvel <ard.biesheuvel@linaro.org> - Benjamin Herrenschmidt <benh@kernel.crashing.org> - Michael Ellerman <mpe@ellerman.id.au> - Tony Luck <tony.luck@intel.com> - Fenghua Yu <fenghua.yu@intel.com> - David S. Miller <davem@davemloft.net> - x86@kernel.org - Christoph Lameter <cl@linux.com> - Pekka Enberg <penberg@kernel.org> - David Rientjes <rientjes@google.com> - Joonsoo Kim <iamjoonsoo.kim@lge.com> - Andrew Morton <akpm@linux-foundation.org> - Andy Lutomirski <luto@kernel.org> - Borislav Petkov <bp@suse.de> - Mathias Krause <minipli@googlemail.com> - Jan Kara <jack@suse.cz> - Vitaly Wool <vitalywool@gmail.com> - Andrea Arcangeli <aarcange@redhat.com> - Dmitry Vyukov <dvyukov@google.com> - Laura Abbott <labbott@fedoraproject.org> - linux-arm-kernel@lists.infradead.org - linux-ia64@vger.kernel.org - linuxppc-dev@lists.ozlabs.org - sparclinux@vger.kernel.org - linux-arch@vger.kernel.org - linux-mm@kvack.org - " kernel-hardening@lists.openwall.com\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote:\n" "> Hi,\n" - ">\302\240\n" + ">?\n" "> [I'm going to carry this series in my kspp -next tree now, though I'd\n" "> really love to have some explicit Acked-bys or Reviewed-bys. If you've\n" "> looked through it or tested it, please consider it. :) (I added Valdis\n" "> and mpe's Tested-bys where they seemed correct, thank you!)]\n" - ">\302\240\n" + ">?\n" "> This is a start of the mainline port of PAX_USERCOPY[1]. After I started\n" "> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I kept\n" "> tweaking things further and further until I ended up with a whole new\n" "> patch series. To that end, I took Rik and other people's feedback along\n" "> with other changes and clean-ups.\n" - ">\302\240\n" + ">?\n" "> Based on my understanding, PAX_USERCOPY was designed to catch a\n" "> few classes of flaws (mainly bad bounds checking) around the use of\n" "> copy_to_user()/copy_from_user(). These changes don't touch get_user() and\n" @@ -67,72 +30,72 @@ "> (this) and CONFIG_HARDENED_USERCOPY_WHITELIST (future), and\n" "> PAX_USERCOPY_SLABS covers CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC\n" "> (future).)\n" - ">\302\240\n" + ">?\n" "> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects\n" "> being copied to/from userspace meet certain criteria:\n" "> - if address is a heap object, the size must not exceed the object's\n" - "> \302\240 allocated size. (This will catch all kinds of heap overflow flaws.)\n" + "> ? allocated size. (This will catch all kinds of heap overflow flaws.)\n" "> - if address range is in the current process stack, it must be within the\n" - "> \302\240 current stack frame (if such checking is possible) or at least entirely\n" - "> \302\240 within the current process's stack. (This could catch large lengths that\n" - "> \302\240 would have extended beyond the current process stack, or overflows if\n" - "> \302\240 their length extends back into the original stack.)\n" + "> ? current stack frame (if such checking is possible) or at least entirely\n" + "> ? within the current process's stack. (This could catch large lengths that\n" + "> ? would have extended beyond the current process stack, or overflows if\n" + "> ? their length extends back into the original stack.)\n" "> - if the address range is part of kernel data, rodata, or bss, allow it.\n" "> - if address range is page-allocated, that it doesn't span multiple\n" - "> \302\240 allocations.\n" + "> ? allocations.\n" "> - if address is within the kernel text, reject it.\n" "> - everything else is accepted\n" - ">\302\240\n" + ">?\n" "> The patches in the series are:\n" "> - Support for arch-specific stack frame checking (which will likely be\n" - "> \302\240 replaced in the future by Josh's more comprehensive unwinder):\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2401- mm: Implement stack frame object validation\n" + "> ? replaced in the future by Josh's more comprehensive unwinder):\n" + "> ????????1- mm: Implement stack frame object validation\n" "> - The core copy_to/from_user() checks, without the slab object checks:\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2402- mm: Hardened usercopy\n" + "> ????????2- mm: Hardened usercopy\n" "> - Per-arch enablement of the protection:\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2403- x86/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2404- ARM: uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2405- arm64/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2406- ia64/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2407- powerpc/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2408- sparc/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2409- s390/uaccess: Enable hardened usercopy\n" + "> ????????3- x86/uaccess: Enable hardened usercopy\n" + "> ????????4- ARM: uaccess: Enable hardened usercopy\n" + "> ????????5- arm64/uaccess: Enable hardened usercopy\n" + "> ????????6- ia64/uaccess: Enable hardened usercopy\n" + "> ????????7- powerpc/uaccess: Enable hardened usercopy\n" + "> ????????8- sparc/uaccess: Enable hardened usercopy\n" + "> ????????9- s390/uaccess: Enable hardened usercopy\n" "> - The heap allocator implementation of object size checking:\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\24010- mm: SLAB hardened usercopy support\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\24011- mm: SLUB hardened usercopy support\n" - ">\302\240\n" + "> ???????10- mm: SLAB hardened usercopy support\n" + "> ???????11- mm: SLUB hardened usercopy support\n" + ">?\n" "> Some notes:\n" - ">\302\240\n" + ">?\n" "> - This is expected to apply on top of -next which contains fixes for the\n" - "> \302\240 position of _etext on both arm and arm64, though it has minor conflicts\n" - "> \302\240 with KASAN that are trivial to fix up. Living in -next are also tests\n" - "> \302\240 for this protection in lkdtm, prefixed with USERCOPY_.\n" - ">\302\240\n" + "> ? position of _etext on both arm and arm64, though it has minor conflicts\n" + "> ? with KASAN that are trivial to fix up. Living in -next are also tests\n" + "> ? for this protection in lkdtm, prefixed with USERCOPY_.\n" + ">?\n" "> - I couldn't detect a measurable performance change with these features\n" - "> \302\240 enabled. Kernel build times were unchanged, hackbench was unchanged,\n" - "> \302\240 etc. I think we could flip this to \"on by default\" at some point, but\n" - "> \302\240 for now, I'm leaving it off until I can get some more definitive\n" - "> \302\240 measurements. I would love if someone with greater familiarity with\n" - "> \302\240 perf could give this a spin and report results.\n" - ">\302\240\n" + "> ? enabled. Kernel build times were unchanged, hackbench was unchanged,\n" + "> ? etc. I think we could flip this to \"on by default\" at some point, but\n" + "> ? for now, I'm leaving it off until I can get some more definitive\n" + "> ? measurements. I would love if someone with greater familiarity with\n" + "> ? perf could give this a spin and report results.\n" + ">?\n" "> - The SLOB support extracted from grsecurity seems entirely broken. I\n" - "> \302\240 have no idea what's going on there, I spent my time testing SLAB and\n" - "> \302\240 SLUB. Having someone else look at SLOB would be nice, but this series\n" - "> \302\240 doesn't depend on it.\n" - ">\302\240\n" + "> ? have no idea what's going on there, I spent my time testing SLAB and\n" + "> ? SLUB. Having someone else look at SLOB would be nice, but this series\n" + "> ? doesn't depend on it.\n" + ">?\n" "> Additional features that would be nice, but aren't blocking this series:\n" - ">\302\240\n" + ">?\n" "> - Needs more architecture support for stack frame checking (only x86 now,\n" - "> \302\240 but it seems Josh will have a good solution for this soon).\n" - ">\302\240\n" - ">\302\240\n" + "> ? but it seems Josh will have a good solution for this soon).\n" + ">?\n" + ">?\n" "> Thanks!\n" - ">\302\240\n" + ">?\n" "> -Kees\n" - ">\302\240\n" + ">?\n" "> [1] https://grsecurity.net/download.php \"grsecurity - test kernel patch\"\n" "> [2] http://www.openwall.com/lists/kernel-hardening/2016/05/19/5\n" - ">\302\240\n" + ">?\n" "> v3:\n" "> - switch to using BUG for better Oops integration\n" "> - when checking page allocations, check each for Reserved\n" @@ -141,6 +104,6 @@ "\n" "Thanks looks good so far! I'll try and test it and report back\n" "\n" - Balbir + Balbir? -e9a5f4acf13b4d5551096ae398377be350365f5d19dd16aea95c0f7a00d57642 +a747015ac60eacbcfe7d231db3450a0982440ade651f969cee74311a93a2680b
diff --git a/a/1.txt b/N5/1.txt index 9684118..68608e2 100644 --- a/a/1.txt +++ b/N5/1.txt @@ -1,17 +1,17 @@ On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote: > Hi, -> +>A > [I'm going to carry this series in my kspp -next tree now, though I'd > really love to have some explicit Acked-bys or Reviewed-bys. If you've > looked through it or tested it, please consider it. :) (I added Valdis > and mpe's Tested-bys where they seemed correct, thank you!)] -> +>A > This is a start of the mainline port of PAX_USERCOPY[1]. After I started > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I kept > tweaking things further and further until I ended up with a whole new > patch series. To that end, I took Rik and other people's feedback along > with other changes and clean-ups. -> +>A > Based on my understanding, PAX_USERCOPY was designed to catch a > few classes of flaws (mainly bad bounds checking) around the use of > copy_to_user()/copy_from_user(). These changes don't touch get_user() and @@ -23,72 +23,72 @@ On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote: > (this) and CONFIG_HARDENED_USERCOPY_WHITELIST (future), and > PAX_USERCOPY_SLABS covers CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC > (future).) -> +>A > 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.) +> A 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.) +> A current stack frame (if such checking is possible) or at least entirely +> A within the current process's stack. (This could catch large lengths that +> A would have extended beyond the current process stack, or overflows if +> A 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. +> A allocations. > - if address is within the kernel text, reject it. > - everything else is accepted -> +>A > The patches in the series are: > - Support for arch-specific stack frame checking (which will likely be -> replaced in the future by Josh's more comprehensive unwinder): -> 1- mm: Implement stack frame object validation +> A replaced in the future by Josh's more comprehensive unwinder): +> A A A A A A A A 1- mm: Implement stack frame object validation > - The core copy_to/from_user() checks, without the slab object checks: -> 2- mm: Hardened usercopy +> A A A A A A A A 2- mm: Hardened usercopy > - Per-arch enablement of the protection: -> 3- x86/uaccess: Enable hardened usercopy -> 4- ARM: uaccess: Enable hardened usercopy -> 5- arm64/uaccess: Enable hardened usercopy -> 6- ia64/uaccess: Enable hardened usercopy -> 7- powerpc/uaccess: Enable hardened usercopy -> 8- sparc/uaccess: Enable hardened usercopy -> 9- s390/uaccess: Enable hardened usercopy +> A A A A A A A A 3- x86/uaccess: Enable hardened usercopy +> A A A A A A A A 4- ARM: uaccess: Enable hardened usercopy +> A A A A A A A A 5- arm64/uaccess: Enable hardened usercopy +> A A A A A A A A 6- ia64/uaccess: Enable hardened usercopy +> A A A A A A A A 7- powerpc/uaccess: Enable hardened usercopy +> A A A A A A A A 8- sparc/uaccess: Enable hardened usercopy +> A A A A A A A A 9- s390/uaccess: Enable hardened usercopy > - The heap allocator implementation of object size checking: -> 10- mm: SLAB hardened usercopy support -> 11- mm: SLUB hardened usercopy support -> +> A A A A A A A 10- mm: SLAB hardened usercopy support +> A A A A A A A 11- mm: SLUB hardened usercopy support +>A > Some notes: -> +>A > - This is expected to apply on top of -next which contains fixes for the -> position of _etext on both arm and arm64, though it has minor conflicts -> with KASAN that are trivial to fix up. Living in -next are also tests -> for this protection in lkdtm, prefixed with USERCOPY_. -> +> A position of _etext on both arm and arm64, though it has minor conflicts +> A with KASAN that are trivial to fix up. Living in -next are also tests +> A for this protection in lkdtm, prefixed with USERCOPY_. +>A > - 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, but -> for now, I'm leaving it off until I can get some more definitive -> measurements. I would love if someone with greater familiarity with -> perf could give this a spin and report results. -> +> A enabled. Kernel build times were unchanged, hackbench was unchanged, +> A etc. I think we could flip this to "on by default" at some point, but +> A for now, I'm leaving it off until I can get some more definitive +> A measurements. I would love if someone with greater familiarity with +> A perf could give this a spin and report results. +>A > - 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. -> +> A have no idea what's going on there, I spent my time testing SLAB and +> A SLUB. Having someone else look at SLOB would be nice, but this series +> A doesn't depend on it. +>A > Additional features that would be nice, but aren't blocking this series: -> +>A > - Needs more architecture support for stack frame checking (only x86 now, -> but it seems Josh will have a good solution for this soon). -> -> +> A but it seems Josh will have a good solution for this soon). +>A +>A > Thanks! -> +>A > -Kees -> +>A > [1] https://grsecurity.net/download.php "grsecurity - test kernel patch" > [2] http://www.openwall.com/lists/kernel-hardening/2016/05/19/5 -> +>A > v3: > - switch to using BUG for better Oops integration > - when checking page allocations, check each for Reserved @@ -97,4 +97,10 @@ On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote: Thanks looks good so far! I'll try and test it and report back -Balbir +BalbirA + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N5/content_digest index a72c3eb..692fbdc 100644 --- a/a/content_digest +++ b/N5/content_digest @@ -1,6 +1,6 @@ "ref\01468619065-3222-1-git-send-email-keescook@chromium.org\0" "From\0Balbir Singh <bsingharora@gmail.com>\0" - "Subject\0[kernel-hardening] Re: [PATCH v3 00/11] mm: Hardened usercopy\0" + "Subject\0Re: [PATCH v3 00/11] mm: Hardened usercopy\0" "Date\0Mon, 18 Jul 2016 18:26:43 +1000\0" "To\0Kees Cook <keescook@chromium.org>" " linux-kernel@vger.kernel.org\0" @@ -44,18 +44,18 @@ "b\0" "On Fri, 2016-07-15 at 14:44 -0700, Kees Cook wrote:\n" "> Hi,\n" - ">\302\240\n" + ">A \n" "> [I'm going to carry this series in my kspp -next tree now, though I'd\n" "> really love to have some explicit Acked-bys or Reviewed-bys. If you've\n" "> looked through it or tested it, please consider it. :) (I added Valdis\n" "> and mpe's Tested-bys where they seemed correct, thank you!)]\n" - ">\302\240\n" + ">A \n" "> This is a start of the mainline port of PAX_USERCOPY[1]. After I started\n" "> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I kept\n" "> tweaking things further and further until I ended up with a whole new\n" "> patch series. To that end, I took Rik and other people's feedback along\n" "> with other changes and clean-ups.\n" - ">\302\240\n" + ">A \n" "> Based on my understanding, PAX_USERCOPY was designed to catch a\n" "> few classes of flaws (mainly bad bounds checking) around the use of\n" "> copy_to_user()/copy_from_user(). These changes don't touch get_user() and\n" @@ -67,72 +67,72 @@ "> (this) and CONFIG_HARDENED_USERCOPY_WHITELIST (future), and\n" "> PAX_USERCOPY_SLABS covers CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC\n" "> (future).)\n" - ">\302\240\n" + ">A \n" "> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects\n" "> being copied to/from userspace meet certain criteria:\n" "> - if address is a heap object, the size must not exceed the object's\n" - "> \302\240 allocated size. (This will catch all kinds of heap overflow flaws.)\n" + "> A allocated size. (This will catch all kinds of heap overflow flaws.)\n" "> - if address range is in the current process stack, it must be within the\n" - "> \302\240 current stack frame (if such checking is possible) or at least entirely\n" - "> \302\240 within the current process's stack. (This could catch large lengths that\n" - "> \302\240 would have extended beyond the current process stack, or overflows if\n" - "> \302\240 their length extends back into the original stack.)\n" + "> A current stack frame (if such checking is possible) or at least entirely\n" + "> A within the current process's stack. (This could catch large lengths that\n" + "> A would have extended beyond the current process stack, or overflows if\n" + "> A their length extends back into the original stack.)\n" "> - if the address range is part of kernel data, rodata, or bss, allow it.\n" "> - if address range is page-allocated, that it doesn't span multiple\n" - "> \302\240 allocations.\n" + "> A allocations.\n" "> - if address is within the kernel text, reject it.\n" "> - everything else is accepted\n" - ">\302\240\n" + ">A \n" "> The patches in the series are:\n" "> - Support for arch-specific stack frame checking (which will likely be\n" - "> \302\240 replaced in the future by Josh's more comprehensive unwinder):\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2401- mm: Implement stack frame object validation\n" + "> A replaced in the future by Josh's more comprehensive unwinder):\n" + "> A A A A A A A A 1- mm: Implement stack frame object validation\n" "> - The core copy_to/from_user() checks, without the slab object checks:\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2402- mm: Hardened usercopy\n" + "> A A A A A A A A 2- mm: Hardened usercopy\n" "> - Per-arch enablement of the protection:\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2403- x86/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2404- ARM: uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2405- arm64/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2406- ia64/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2407- powerpc/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2408- sparc/uaccess: Enable hardened usercopy\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2409- s390/uaccess: Enable hardened usercopy\n" + "> A A A A A A A A 3- x86/uaccess: Enable hardened usercopy\n" + "> A A A A A A A A 4- ARM: uaccess: Enable hardened usercopy\n" + "> A A A A A A A A 5- arm64/uaccess: Enable hardened usercopy\n" + "> A A A A A A A A 6- ia64/uaccess: Enable hardened usercopy\n" + "> A A A A A A A A 7- powerpc/uaccess: Enable hardened usercopy\n" + "> A A A A A A A A 8- sparc/uaccess: Enable hardened usercopy\n" + "> A A A A A A A A 9- s390/uaccess: Enable hardened usercopy\n" "> - The heap allocator implementation of object size checking:\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\24010- mm: SLAB hardened usercopy support\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\24011- mm: SLUB hardened usercopy support\n" - ">\302\240\n" + "> A A A A A A A 10- mm: SLAB hardened usercopy support\n" + "> A A A A A A A 11- mm: SLUB hardened usercopy support\n" + ">A \n" "> Some notes:\n" - ">\302\240\n" + ">A \n" "> - This is expected to apply on top of -next which contains fixes for the\n" - "> \302\240 position of _etext on both arm and arm64, though it has minor conflicts\n" - "> \302\240 with KASAN that are trivial to fix up. Living in -next are also tests\n" - "> \302\240 for this protection in lkdtm, prefixed with USERCOPY_.\n" - ">\302\240\n" + "> A position of _etext on both arm and arm64, though it has minor conflicts\n" + "> A with KASAN that are trivial to fix up. Living in -next are also tests\n" + "> A for this protection in lkdtm, prefixed with USERCOPY_.\n" + ">A \n" "> - I couldn't detect a measurable performance change with these features\n" - "> \302\240 enabled. Kernel build times were unchanged, hackbench was unchanged,\n" - "> \302\240 etc. I think we could flip this to \"on by default\" at some point, but\n" - "> \302\240 for now, I'm leaving it off until I can get some more definitive\n" - "> \302\240 measurements. I would love if someone with greater familiarity with\n" - "> \302\240 perf could give this a spin and report results.\n" - ">\302\240\n" + "> A enabled. Kernel build times were unchanged, hackbench was unchanged,\n" + "> A etc. I think we could flip this to \"on by default\" at some point, but\n" + "> A for now, I'm leaving it off until I can get some more definitive\n" + "> A measurements. I would love if someone with greater familiarity with\n" + "> A perf could give this a spin and report results.\n" + ">A \n" "> - The SLOB support extracted from grsecurity seems entirely broken. I\n" - "> \302\240 have no idea what's going on there, I spent my time testing SLAB and\n" - "> \302\240 SLUB. Having someone else look at SLOB would be nice, but this series\n" - "> \302\240 doesn't depend on it.\n" - ">\302\240\n" + "> A have no idea what's going on there, I spent my time testing SLAB and\n" + "> A SLUB. Having someone else look at SLOB would be nice, but this series\n" + "> A doesn't depend on it.\n" + ">A \n" "> Additional features that would be nice, but aren't blocking this series:\n" - ">\302\240\n" + ">A \n" "> - Needs more architecture support for stack frame checking (only x86 now,\n" - "> \302\240 but it seems Josh will have a good solution for this soon).\n" - ">\302\240\n" - ">\302\240\n" + "> A but it seems Josh will have a good solution for this soon).\n" + ">A \n" + ">A \n" "> Thanks!\n" - ">\302\240\n" + ">A \n" "> -Kees\n" - ">\302\240\n" + ">A \n" "> [1] https://grsecurity.net/download.php \"grsecurity - test kernel patch\"\n" "> [2] http://www.openwall.com/lists/kernel-hardening/2016/05/19/5\n" - ">\302\240\n" + ">A \n" "> v3:\n" "> - switch to using BUG for better Oops integration\n" "> - when checking page allocations, check each for Reserved\n" @@ -141,6 +141,12 @@ "\n" "Thanks looks good so far! I'll try and test it and report back\n" "\n" - Balbir + "BalbirA \n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -e9a5f4acf13b4d5551096ae398377be350365f5d19dd16aea95c0f7a00d57642 +714835b239549b2a4f04b2fafc5c3d6de5f42a8dac74b640f1a27ff79322de0d
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.