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

Groups > linux.kernel > #1606936 > unrolled thread

Re: [PATCH 5/6] notifiers: Use CHECK_DATA_CORRUPTION() on checks

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 5/6] notifiers: Use CHECK_DATA_CORRUPTION() on checks Kees Cook <keescook@chromium.org> - 2017-03-22 20:30 +0100
    Re: [PATCH 5/6] notifiers: Use CHECK_DATA_CORRUPTION() on checks Arjan van de Ven <arjan@linux.intel.com> - 2017-03-22 20:40 +0100
      Re: [PATCH 5/6] notifiers: Use CHECK_DATA_CORRUPTION() on checks Kees Cook <keescook@chromium.org> - 2017-03-22 21:00 +0100

#1606936 — Re: [PATCH 5/6] notifiers: Use CHECK_DATA_CORRUPTION() on checks

On Mon, Mar 6, 2017 at 11:09 AM, Kees Cook <keescook@chromium.org> wrote:
> When performing notifier function pointer sanity checking, allow
> CONFIG_BUG_ON_DATA_CORRUPTION to upgrade from a WARN to a BUG.
> Additionally enables CONFIG_DEBUG_NOTIFIERS when selecting
> CONFIG_BUG_ON_DATA_CORRUPTION.

Any feedback on this change? By default, this retains the existing
WARN behavior...

-Kees

>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  kernel/notifier.c | 5 +++--
>  lib/Kconfig.debug | 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/notifier.c b/kernel/notifier.c
> index 6196af8a8223..58cc14958d92 100644
> --- a/kernel/notifier.c
> +++ b/kernel/notifier.c
> @@ -84,8 +84,9 @@ static int notifier_call_chain(struct notifier_block **nl,
>                 next_nb = rcu_dereference_raw(nb->next);
>
>  #ifdef CONFIG_DEBUG_NOTIFIERS
> -               if (unlikely(!func_ptr_is_kernel_text(nb->notifier_call))) {
> -                       WARN(1, "Invalid notifier called!");
> +               if (CHECK_DATA_CORRUPTION(
> +                               !func_ptr_is_kernel_text(nb->notifier_call),
> +                               "Invalid notifier called!")) {
>                         nb = next_nb;
>                         continue;
>                 }
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 42c61cfe7d19..70e9f2c1bb30 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1277,7 +1277,7 @@ config DEBUG_SG
>
>  config DEBUG_NOTIFIERS
>         bool "Debug notifier call chains"
> -       depends on DEBUG_KERNEL
> +       depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
>         help
>           Enable this to turn on sanity checking for notifier call chains.
>           This is most useful for kernel developers to make sure that
> @@ -1995,6 +1995,7 @@ config BUG_ON_DATA_CORRUPTION
>         bool "Trigger a BUG when data corruption is detected"
>         select DEBUG_CREDENTIALS
>         select DEBUG_LIST
> +       select DEBUG_NOTIFIERS
>         select DEBUG_SG
>         help
>           This option enables several inexpensive data corruption checks.
> --
> 2.7.4
>



-- 
Kees Cook
Pixel Security

[toc] | [next] | [standalone]

#1606942

On 3/22/2017 12:29 PM, Kees Cook wrote:
>> When performing notifier function pointer sanity checking, allow
>> CONFIG_BUG_ON_DATA_CORRUPTION to upgrade from a WARN to a BUG.
>> Additionally enables CONFIG_DEBUG_NOTIFIERS when selecting
>> CONFIG_BUG_ON_DATA_CORRUPTION.

> Any feedback on this change? By default, this retains the existing
> WARN behavior...

if you're upgrading, is the end point really a panic() ?
e.g. do you assume people to also set panic-on-oops?

[toc] | [prev] | [next] | [standalone]

#1606951

On Wed, Mar 22, 2017 at 12:32 PM, Arjan van de Ven
<arjan@linux.intel.com> wrote:
> On 3/22/2017 12:29 PM, Kees Cook wrote:
>>>
>>> When performing notifier function pointer sanity checking, allow
>>> CONFIG_BUG_ON_DATA_CORRUPTION to upgrade from a WARN to a BUG.
>>> Additionally enables CONFIG_DEBUG_NOTIFIERS when selecting
>>> CONFIG_BUG_ON_DATA_CORRUPTION.
>
>
>> Any feedback on this change? By default, this retains the existing
>> WARN behavior...
>
>
> if you're upgrading, is the end point really a panic() ?
> e.g. do you assume people to also set panic-on-oops?

That's one option, yes. With the BUG, the process associated is killed
(which is the first level of defense upgrade), and if a system is also
set to panic-on-oops, the entire system will panic (and usually such
systems also retain their crash consoles in some fashion for later
analysis, etc).

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web