Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1444529
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy |
| Date | 2016-07-15 21:20 +0200 |
| Message-ID | <rVgOt-2mh-7@gated-at.bofh.it> (permalink) |
| References | <rUAmd-nH-3@gated-at.bofh.it> <rUAmj-nH-27@gated-at.bofh.it> <rUYeS-7FM-5@gated-at.bofh.it> <rV2Vb-2fz-1@gated-at.bofh.it> <rVgEP-2iR-45@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Jul 15, 2016 at 12:00 PM, Daniel Micay <danielmicay@gmail.com> wrote: >> 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=1. > > 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. I'd like it to dump stack and be fatal to the process involved, but yeah, I guess BUG() would work. Creating an infrastructure for handling security-related Oopses can be done separately from this (and I'd like to see that added, since it's a nice bit of configurable reactivity to possible attacks). -Kees -- Kees Cook Chrome OS & Brillo Security
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH v2 02/11] mm: Hardened usercopy Kees Cook <keescook@chromium.org> - 2016-07-14 00:00 +0200
Re: [PATCH v2 02/11] mm: Hardened usercopy Balbir Singh <bsingharora@gmail.com> - 2016-07-15 01:30 +0200
Re: [PATCH v2 02/11] mm: Hardened usercopy Rik van Riel <riel@redhat.com> - 2016-07-15 03:10 +0200
Re: [PATCH v2 02/11] mm: Hardened usercopy Balbir Singh <bsingharora@gmail.com> - 2016-07-15 03:50 +0200
Re: [PATCH v2 02/11] mm: Hardened usercopy Kees Cook <keescook@chromium.org> - 2016-07-15 06:10 +0200
Re: [PATCH v2 02/11] mm: Hardened usercopy Kees Cook <keescook@chromium.org> - 2016-07-15 07:00 +0200
Re: [PATCH v2 02/11] mm: Hardened usercopy Balbir Singh <bsingharora@gmail.com> - 2016-07-15 15:00 +0200
Re: [PATCH v2 02/11] mm: Hardened usercopy Kees Cook <keescook@chromium.org> - 2016-07-15 06:30 +0200
Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy Daniel Micay <danielmicay@gmail.com> - 2016-07-15 21:10 +0200
Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy Daniel Micay <danielmicay@gmail.com> - 2016-07-15 21:20 +0200
Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy Kees Cook <keescook@chromium.org> - 2016-07-15 21:30 +0200
Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy Kees Cook <keescook@chromium.org> - 2016-07-15 21:20 +0200
csiph-web