From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Micay Subject: Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy Date: Fri, 15 Jul 2016 15:00:54 -0400 Message-ID: <1468609254.32683.34.camel@gmail.com> References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-iJ67bgEOqJPCpsbunZkk" Return-path: Received: from mail-qk0-f177.google.com ([209.85.220.177]:36652 "EHLO mail-qk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751615AbcGOTBV (ORCPT ); Fri, 15 Jul 2016 15:01:21 -0400 In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: kernel-hardening@lists.openwall.com, bsingharora@gmail.com Cc: LKML , Rik van Riel , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause J --=-iJ67bgEOqJPCpsbunZkk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > This could be a BUG, but I'd rather not panic the entire kernel. It seems unlikely that it will panic without panic_on_oops and that's an explicit opt-in to taking down the system on kernel logic errors exactly like this. In grsecurity, it calls the kernel exploit handling logic (panic if root, otherwise kill all process of that user and ban them until reboot) but that same logic is also called for BUG via oops handling so there's only really a distinction with panic_on_oops=3D1. Does it make sense to be less fatal for a fatal assertion that's more likely to be security-related? Maybe you're worried about having some false positives for the whitelisting portion, but I don't think those will lurk around very long with the way this works. --=-iJ67bgEOqJPCpsbunZkk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdBQJXiTLmFhxkYW5pZWxtaWNheUBnbWFpbC5jb20ACgkQ+ecS5Zr1 8ipfHQ/9GuB4gHqH46EsTlmQ5fcWXnwNJB5FATNyKhlxyXfCcEGojs2+G059y/C5 iIp7FmOqCknF/Aj7c/owNO28BFPBdpetDI4a2HTto0zFCtD69qpGjJ4wWmgYBkUb he2J5Lok020qi4ffWmNy1fgjkyfkUU4cGDaosxKbXcOe1mgmhi7ghnsXcqeEU4ii HCNFvYgV0hVKQHvrWIUW51r3j1fWWR22bghGy0wHLWrFeOhX1d5WK9TfzfSUZdTz /g+4Wji0OKpI+75VYJc2P35LxTsSN0JT8XDicnus4+4l8MGc6TW4Z9AZBK7lZEK5 nhFWXS926xNGc1c5NPQzkEtgUKoeEbAeMcdyFd8k/JfOLas0WAF+iqVGAP/DlxHm WTFcfvOpTArS7MMdfB6v3yj7ZOsVPCJAakuJdVCvXCKLAISy86p2EZT43vggz2q2 FJORgUNfHfmGiZy9r+MHTBtwAS+Gn9Z77gmQcMb0pVdHVj4l+QkEcSkdliOcVJ4c 6ITvBCD0F+1CiNTUIJ9oYlW92iqUX9M2QweDrlQ1PbWQVjyZU7NWh1VWmAsnhFBO OE0GVO34OySR+FpVyqH7keEbb5e0P4ECC1e0UwxMfUZIpqMPT+g/9WAIJay6gVLk 6JVsWwkgg2nYyVFwvmP7gnUCeQB4ckhH08Ki7gjt0BidNywxfkU= =PaWF -----END PGP SIGNATURE----- --=-iJ67bgEOqJPCpsbunZkk-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f177.google.com ([209.85.220.177]:36652 "EHLO mail-qk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751615AbcGOTBV (ORCPT ); Fri, 15 Jul 2016 15:01:21 -0400 Message-ID: <1468609254.32683.34.camel@gmail.com> Subject: Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy From: Daniel Micay Date: Fri, 15 Jul 2016 15:00:54 -0400 In-Reply-To: References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-iJ67bgEOqJPCpsbunZkk" Mime-Version: 1.0 Sender: linux-arch-owner@vger.kernel.org List-ID: To: kernel-hardening@lists.openwall.com, bsingharora@gmail.com Cc: LKML , Rik van Riel , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , "linux-arm-kernel@lists.infradead.org" , linux-ia64@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" , sparclinux , linux-arch , Linux-MM Message-ID: <20160715190054.8esuqQft_SEvuT9hoKI7c3YNf8b7O54kgvY51IVCBqM@z> --=-iJ67bgEOqJPCpsbunZkk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > This could be a BUG, but I'd rather not panic the entire kernel. It seems unlikely that it will panic without panic_on_oops and that's an explicit opt-in to taking down the system on kernel logic errors exactly like this. In grsecurity, it calls the kernel exploit handling logic (panic if root, otherwise kill all process of that user and ban them until reboot) but that same logic is also called for BUG via oops handling so there's only really a distinction with panic_on_oops=3D1. Does it make sense to be less fatal for a fatal assertion that's more likely to be security-related? Maybe you're worried about having some false positives for the whitelisting portion, but I don't think those will lurk around very long with the way this works. --=-iJ67bgEOqJPCpsbunZkk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdBQJXiTLmFhxkYW5pZWxtaWNheUBnbWFpbC5jb20ACgkQ+ecS5Zr1 8ipfHQ/9GuB4gHqH46EsTlmQ5fcWXnwNJB5FATNyKhlxyXfCcEGojs2+G059y/C5 iIp7FmOqCknF/Aj7c/owNO28BFPBdpetDI4a2HTto0zFCtD69qpGjJ4wWmgYBkUb he2J5Lok020qi4ffWmNy1fgjkyfkUU4cGDaosxKbXcOe1mgmhi7ghnsXcqeEU4ii HCNFvYgV0hVKQHvrWIUW51r3j1fWWR22bghGy0wHLWrFeOhX1d5WK9TfzfSUZdTz /g+4Wji0OKpI+75VYJc2P35LxTsSN0JT8XDicnus4+4l8MGc6TW4Z9AZBK7lZEK5 nhFWXS926xNGc1c5NPQzkEtgUKoeEbAeMcdyFd8k/JfOLas0WAF+iqVGAP/DlxHm WTFcfvOpTArS7MMdfB6v3yj7ZOsVPCJAakuJdVCvXCKLAISy86p2EZT43vggz2q2 FJORgUNfHfmGiZy9r+MHTBtwAS+Gn9Z77gmQcMb0pVdHVj4l+QkEcSkdliOcVJ4c 6ITvBCD0F+1CiNTUIJ9oYlW92iqUX9M2QweDrlQ1PbWQVjyZU7NWh1VWmAsnhFBO OE0GVO34OySR+FpVyqH7keEbb5e0P4ECC1e0UwxMfUZIpqMPT+g/9WAIJay6gVLk 6JVsWwkgg2nYyVFwvmP7gnUCeQB4ckhH08Ki7gjt0BidNywxfkU= =PaWF -----END PGP SIGNATURE----- --=-iJ67bgEOqJPCpsbunZkk--