On 19/12/17 04:12, Alexei Starovoitov wrote:
> Also reduce the scope of "scalar op scalar" tracking.
<snip>
> @@ -2046,6 +2088,12 @@ static int adjust_scalar_min_max_vals(struct
> bpf_verifier_env *env,
> src_known = tnum_is_const(src_reg.var_off);
> dst_known = tnum_is_const(dst_reg->var_off);
>
> + if (!src_known &&
> + opcode != BPF_ADD && opcode != BPF_SUB && opcode != BPF_AND) {
> + __mark_reg_unknown(dst_reg);
> + return 0;
> + }
> +
> switch (opcode) {
> case BPF_ADD:
> if (signed_add_overflows(dst_reg->smin_value, smin_val) ||
Still not seeing any explanation for why this change is necessary.
It also seems arbitrary, e.g. why is AND allowed but not OR?
Hypothetical use case: combining a series of flags based on data read from
packet into an array index used for storing into a map value. That sounds
to me like something someone may be legitimately doing.
-Ed
