Hi, Jeffrey,
I plugged in your function into samples/bpf/xdp1_kern.c and
manipulated it with multiple calls but did not get your problems
triggered. If you can send me the complete example, I may help debug
and tell what is the exact reason and why anything verifier needs
improvement or not.
Thanks,
Yonghong
On Thu, Jun 22, 2017 at 3:03 AM, Panneman, J.J. (Jeffrey)
<jeffrey.panneman@xxxxxx> wrote:
> Hi all,
>
> I spent sometime trying to figure out how I should check or guard for overflows but I could not find, let's say a default way from the samples in the kernel repo.
> After some experimentation my issue seemed to disappear when I changed my uint64_t variable, which I use to keep track of my position in the payload to a uint8_t type. I now have no issue adding the values multiple times, but I would like to know why this solved my problem. Happy to provide verifier log or so.
>
> For some context, I was doing the following:
> I had a method (tlv_amount_of_octets) that returned a value based on a switch statement; this value was then put into a uint8_t variable.
> I then tried to add this uint8_t value to my uint64_t variable to increase the payload_position by that return value. I have added the snippet at the end of the message.
> When doing this a singular time it worked fine, or when adding a static value such as 1. When doing it a second time, I started getting the error in question: ' cannot add integer value with 0 upper zero bits to ptr_to_packet'.
>
> Kind regards,
>
> Jeffrey Panneman
>
> ------------------------------------------------- Start of Snippet -----------------------------------
>
> static __always_inline uint8_t tlv_amount_of_octets(uint8_t *data, uint64_t payload_position) {
> uint8_t first_octet = data[payload_position];
> uint8_t amount_of_octets = 1;
>
> if (first_octet<253)
> amount_of_octets = 1;
> else {
> //length encoded in following 2,4,or 8 octets
> switch (first_octet) {
> case 253:
> amount_of_octets = 2;
> break;
> case 254:
> amount_of_octets = 4;
> break;
> case 255:
> amount_of_octets = 8;
> break;
> }
> amount_of_octets++; //account for the fact that first octet plays now indication role
> }
> return amount_of_octets;
> }
>
> -----Original Message-----
> From: Daniel Borkmann [mailto:daniel@xxxxxxxxxxxxx]
> Sent: woensdag 21 juni 2017 19:05
> To: Y Song <ys114321@xxxxxxxxx>; Panneman, J.J. (Jeffrey) <jeffrey.panneman@xxxxxx>
> Cc: xdp-newbies@xxxxxxxxxxxxxxx
> Subject: Re: FW: Cannot add integer value with N upper zero bits to ptr_to_packet
>
> On 06/21/2017 05:55 PM, Y Song wrote:
>> This is a verifier error. Do you have a test case? I can take a
>> further look at this.
>>
>> On Wed, Jun 21, 2017 at 6:35 AM, Panneman, J.J. (Jeffrey)
>> <jeffrey.panneman@xxxxxx> wrote:
>>> Hi All,
>>>
>>> I currently have another issue which seems rather weird. I have a variable with type uint8_t, this is passed as reference to a function in which it gets a value. When I do this a single time, the variable gets a value and I can print it with the trace print call. Now when I do this a second time, I get the 'cannot add integer value with 0 upper zero bits to ptr_to_packet' message, I have also tried to create another variable and assign it to this but this did not resolve anything.
>>>
>>> is there some restrictions on changing values ? The message doesn't really give me enough to work out the exact issue.
>>>
>>> Happy to provide verifier output and code for those who might have an idea.
>
> The error message usually happens when you have register that contains {skb,xdp}->data or some pointer derived from this, and you add another register to it that has a unknown value, where verifier has no knowledge of what the upper bound could be of that register so that it cannot guarantee that this won't turn into a overflow (it expects 48 or more zero upper bits). The passing by reference might not necessarily be the cause for triggering this, but rather the addition that you perform somewhere in your code. Test case would help indeed to see what you're doing.
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
|