On 12/07/17 23:07, Nadav Amit wrote:
> Edward Cree wrote:
>> In this specific case, there was a bug before: if (say) src and dst were
>> both unknown bytes (so range 0 to 255), it would compute the new min and max
>> to be 0, so it would think the result is known to be 0. But that's wrong,
>> bec
Edward Cree wrote:
> On 07/07/17 18:45, Nadav Amit wrote:
>> For me changes such as:
>>
>>> if (dst_reg->min_value != BPF_REGISTER_MIN_RANGE)
>>> - dst_reg->min_value -= min_val;
>>> + dst_reg->min_value -= max_val;
>>
>> are purely cryptic. What happened her
On 07/07/17 18:45, Nadav Amit wrote:
> For me changes such as:
>
>> if (dst_reg->min_value != BPF_REGISTER_MIN_RANGE)
>> -dst_reg->min_value -= min_val;
>> +dst_reg->min_value -= max_val;
>
> are purely cryptic. What happened here? Was there a bu
Nadav Amit wrote:
> Edward Cree wrote:
>
>> On 06/07/17 22:21, Nadav Amit wrote:
>>> I find it a bit surprising that such huge changes that can affect security
>>> and robustness are performed in one patch.
>> In the first version of the series, this was two patches, with "feed
>> pointer-to-un
Edward Cree wrote:
> On 06/07/17 22:21, Nadav Amit wrote:
>> I find it a bit surprising that such huge changes that can affect security
>> and robustness are performed in one patch.
> In the first version of the series, this was two patches, with "feed
> pointer-to-unknown-scalar casts into scala
On 06/07/17 22:21, Nadav Amit wrote:
> I find it a bit surprising that such huge changes that can affect security
> and robustness are performed in one patch.
In the first version of the series, this was two patches, with "feed
pointer-to-unknown-scalar casts into scalar ALU path" split out from t
Edward Cree via iovisor-dev wrote:
> Tracks value alignment by means of tracking known & unknown bits.
> Tightens some min/max value checks and fixes a couple of bugs therein.
> If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES,
> treat the pointer as an unknown scalar and
