On Sat, 2024-08-31 at 14:45 +0900, Jeongjun Park wrote:
> This patch was written to fix an issue where btf_name_valid_section() would
> not properly check names with certain conditions and would throw an OOB vuln.
> And selftest was added to verify this patch.
Acked-by: Eduard Zingerman
[...]
On Tue, 2024-09-24 at 12:55 +0800, zhangjiao2 wrote:
> From: zhang jiao
>
> There is no va_end after va_copy, just add it.
>
> Signed-off-by: zhang jiao
> ---
My bad, thank you for fixing this.
Acked-by: Eduard Zingerman
to use a map type that still requires null checks, as it's
> exercising verifier tracking logic w.r.t iterators.
>
> Signed-off-by: Daniel Xu
> ---
Acked-by: Eduard Zingerman
[...]
> +/* Returns constant key value if possible, else -1 */
> +static long get_constant
up. And obviously some bound checks.
>
> Signed-off-by: Daniel Xu
> ---
Acked-by: Eduard Zingerman
[...]
On Sun, 2024-09-15 at 21:45 -0600, Daniel Xu wrote:
> This commit allows progs to elide a null check on statically known map
> lookup keys. In other words, if the verifier can statically prove that
> the lookup will be in-bounds, allow the prog to drop the null check.
>
> This is useful for two re
On Thu, 2024-12-19 at 21:09 -0700, Daniel Xu wrote:
lgtm, but please see a note below.
[...]
> +/* Returns constant key value if possible, else negative error */
> +static s64 get_constant_map_key(struct bpf_verifier_env *env,
> + struct bpf_reg_state *key,
> +
On Sat, 2025-02-01 at 12:58 -0700, Daniel Xu wrote:
> Test that very high constant map keys are not interpreted as an error
> value by the verifier. This would previously fail.
>
> Signed-off-by: Daniel Xu
> ---
Acked-by: Eduard Zingerman
[...]
tatic);
- when only static libraries are available.
Tested-by: Eduard Zingerman
[...]
On Thu, 2024-12-12 at 16:22 -0700, Daniel Xu wrote:
I think these changes are fine in general, but see below.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 58b36cc96bd5..4947ef884a18 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -287,6 +287,7 @@ st
ates for examples.
>
> Signed-off-by: Daniel Xu
> ---
I think this change is ok.
With it there is only one use of 'enum bpf_access_src' remains,
but it doesn't look like it could be removed.
Acked-by: Eduard Zingerman
[...]
> --- a/tools/testing/selftests/bpf/pr
On Sat, 2024-12-14 at 00:10 +0100, Kumar Kartikeya Dwivedi wrote:
[...]
> > @@ -11199,10 +11266,17 @@ static int check_helper_call(struct
> > bpf_verifier_env *env, struct bpf_insn *insn
> > "kernel subsystem misconfigured
> > verifier\n");
> >
On Fri, 2024-12-13 at 15:14 -0800, Eduard Zingerman wrote:
[...]
> Great point, I'm sure this does not happen.
I mean, mark_chain_precision() does not happen at the moment.
On Thu, 2024-12-12 at 16:22 -0700, Daniel Xu wrote:
> Test that nullness elision works for common use cases. For example, we
> want to check that both full and subreg stack slots are recognized. As
> well as when there's both const and non-const values of R2 leading up to
> a lookup. And obviously
On Fri, 2024-12-13 at 19:44 -0700, Daniel Xu wrote:
[...]
> > > + /* First handle precisely tracked STACK_ZERO, up to BPF_REG_SIZE
> > > */
> > > + stype = state->stack[spi].slot_type;
> > > + for (i = 0; i < BPF_REG_SIZE && stype[i] == STACK_ZERO; i++)
> >
> > it's Friday and
On Thu, 2024-12-19 at 14:41 -0700, Daniel Xu wrote:
[...]
> > > I think that if test operates on a key like:
> > >
> > > valid key 15
> > > v
> > > 000f <-- written to stack as a single u64 value
> > > ^^^
> > > stack zero marks
> > >
> > > and is ex
On Thu, 2024-12-19 at 17:40 -0700, Daniel Xu wrote:
[...]
> > Ok, thinking a bit more, the best test I can come up with is:
> >
> > u8 vals[8];
> > vals[0] = 0;
> > ...
> > vals[6] = 0;
> > vals[7] = 0xf;
> > p = bpf_map_lookup_elem(... vals ...);
> > *p = 42;
> >
> > For LE vals
On Thu, 2024-12-19 at 21:09 -0700, Daniel Xu wrote:
> Test that nullness elision works for common use cases. For example, we
> want to check that both constant scalar spills and STACK_ZERO functions.
> As well as when there's both const and non-const values of R2 leading up
> to a lookup. And obvio
On Thu, 2025-03-13 at 18:21 +0100, Luis Gerhorst wrote:
> This improves the expressiveness of unprivileged BPF by inserting
> speculation barriers instead of rejecting the programs.
>
> The approach was previously presented at LPC'24 [1] and RAID'24 [2].
>
> To mitigate the Spectre v1 (PHT) vulne
gt; Cc: Milan Stephan
> ---
The only pace I'm aware of that might act upon specific error code
from verifier syscall is libbpf. Looking through libbpf code, it seems
that this change does not interfere with libbpf.
Reviewed-by: Eduard Zingerman
[...]
me as for previous patch.
Reviewed-by: Eduard Zingerman
[...]
On Thu, 2025-03-13 at 18:21 +0100, Luis Gerhorst wrote:
> This is required to catch the errors later and fall back to a nospec if
> on a speculative path.
>
> Move code into do_check_insn(), replace
> * "continue" with "return INSN_IDX_MODIFIED"
> * "goto process_bpf_exit" with "return PROCESS_BPF
On Thu, 2025-03-13 at 18:41 +0100, Luis Gerhorst wrote:
[...]
> @@ -2011,8 +2011,10 @@ static struct bpf_verifier_state *push_stack(struct
> bpf_verifier_env *env,
> int err;
>
> elem = kzalloc(sizeof(struct bpf_verifier_stack_elem), GFP_KERNEL);
> - if (!elem)
> -
22 matches
Mail list logo
