netdev - Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <099fa7d4-435a-3fa4-841c-17603a45e77e@fb.com>
Date:   Thu, 28 Dec 2017 17:11:31 -0800
From:   Alexei Starovoitov <ast@...com>
To:     Masami Hiramatsu <mhiramat@...nel.org>
CC:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Josef Bacik <jbacik@...com>, <rostedt@...dmis.org>,
        <mingo@...hat.com>, <davem@...emloft.net>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <ast@...nel.org>, <kernel-team@...com>, <daniel@...earbox.net>,
        <linux-btrfs@...r.kernel.org>, <darrick.wong@...cle.com>,
        Josef Bacik <josef@...icpanda.com>,
        Akinobu Mita <akinobu.mita@...il.com>
Subject: Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault
 injection framework

On 12/27/17 11:51 PM, Masami Hiramatsu wrote:
>
> Then what happen if the user set invalid retval to those functions?
> even if we limit the injectable functions, it can cause a problem,
>
> for example,
>
>  obj = func_return_object();
>  if (!obj) {
>     handling_error...;
>  }
>  obj->field = x;
>
> In this case, obviously func_return_object() must return NULL if there is
> an error, not -ENOMEM. But without the correct retval information, how would
> you check the BPF code doesn't cause a trouble?
> Currently it seems you are expecting only the functions which return error code.
>
>  ret = func_return_state();
>  if (ret < 0) {
>     handling_error...;
>  }
>
> But how we can distinguish those?
>
> If we have the error range for each function, we can ensure what is
> *correct* error code, NULL or errno, or any other error numbers. :)

messing up return values may cause problems and range check is
not going to magically help.
The caller may handle only a certain set of errors or interpret
some of them like EBUSY as a signal to retry.
It's plain impossible to make sure that kernel will be functional
after error injection has been made.
Like kmalloc() unconditionally returning NULL will be deadly
for the kernel, hence this patch 4/4 has very limited practical
use. The bpf program need to make intelligent decisions when
to return an error and what kind of error to return.
Doing blank range check adds a false sense of additional safety.
More so it wastes kilobytes of memory to do this check, hence nack.