Hi,
On Sun, 11 Dec 2022 08:49:01 +0100
KP Singh <kpsingh@xxxxxxxxxx> wrote:
> 1. Revisit what is allowed for error injection in the kernel and if
> they can cause any subtle issues. My initial take is that functions
> that are directly called from syscall path should generally be okay.
> But let's check them for the patterns you mentioned.
> 2. If it helps, add the list of BPF modify return programs to stack
> traces. Although this is really needed if we don't do [1] properly.
> 3. Check if anything needs to be improved in the verification logic
> for modify return trampolines.
Hmm, I found that bpf might not check the acceptable error type of
each ALLOW_ERROR_INJECTION().
Except for EI_ETYPE_NONE, we have 4 types of the error.
EI_ETYPE_NULL, /* Return NULL if failure */
EI_ETYPE_ERRNO, /* Return -ERRNO if failure */
EI_ETYPE_ERRNO_NULL, /* Return -ERRNO or NULL if failure */
EI_ETYPE_TRUE, /* Return true if failure */
These specifies that what return value will be treated as an error
by the caller.
If bpf trampoline only expect that the function will return -errno
in error cases, bpf should check the error type as below.
etype = get_injectable_error_type(addr);
if (etype != EI_ETYPE_ERRNO && etype != EI_ETYPE_ERRNO_NULL)
/* reject it */
If bpf can handle any case, it still need to verify that the user
bpf prog specifies correct return value for each type.
See adjust_error_retval()@kernel/fail_function.c for the available
return values.
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
