Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1444529

Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy

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

Show all headers | View raw


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 | NextPrevious in thread | Find similar | Unroll thread


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