Messages in this thread |  | | Date | Mon, 12 Dec 2022 09:53:33 +0900 | From | Masami Hiramatsu (Google) <> | Subject | Re: [PATCH v2] panic: Taint kernel if fault injection has been used |
| |
Hi,
On Sun, 11 Dec 2022 08:49:01 +0100 KP Singh <kpsingh@kernel.org> 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@kernel.org>
|  |