{"action":"created","issue":{"url":"https://api.github.com/repos/Igalia/pflua/issues/171","labels_url":"https://api.github.com/repos/Igalia/pflua/issues/171/labels{/name}","comments_url":"https://api.github.com/repos/Igalia/pflua/issues/171/comments","events_url":"https://api.github.com/repos/Igalia/pflua/issues/171/events","html_url":"https://github.com/Igalia/pflua/issues/171","id":69839674,"number":171,"title":"Packet indexing should cause conditions and assertions","user":{"login":"andywingo","id":1745903,"avatar_url":"https://avatars.githubusercontent.com/u/1745903?v=3","gravatar_id":"","url":"https://api.github.com/users/andywingo","html_url":"https://github.com/andywingo","followers_url":"https://api.github.com/users/andywingo/followers","following_url":"https://api.github.com/users/andywingo/following{/other_user}","gists_url":"https://api.github.com/users/andywingo/gists{/gist_id}","starred_url":"https://api.github.com/users/andywingo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/andywingo/subscriptions","organizations_url":"https://api.github.com/users/andywingo/orgs","repos_url":"https://api.github.com/users/andywingo/repos","events_url":"https://api.github.com/users/andywingo/events{/privacy}","received_events_url":"https://api.github.com/users/andywingo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-04-21T13:01:05Z","updated_at":"2015-04-22T07:51:22Z","closed_at":null,"body":"The expression \"arp[0] >= 0 or not arp\" should match all packets.  Right now it fails for non-arp packets; see #166.  The issue is that packet access (arp[0]) was causing an *assertion* that the packet is an arp packet.  By *assertion* I mean that if the packet is not an arp packet, the whole filter fails, not just the clause.  Instead, the expansion of arp[0] should simply cause the clause to fail if the packet isn't an arp packet.\r\n\r\nHowever, one assertion does remain: if an out-of-bounds access is made to the packet, the filter immediately fails.  See https://github.com/Igalia/pflua/blob/master/doc/pflang.md#packet-access.  This is an artifact of the implementation of the BPF VMs -- out-of-bounds packet access causes immediate failure.\r\n\r\nSo arithmetic expressions should residualize both *assertions* which cause the filter to fail immediately and *conditions* which cause the clause to fail.\r\n\r\nOne open question is, what is the ordering between conditions and assertions?  Some tests show that e.g. arp[5000] < 42 will test \"arp\" and fail the clause before accessing the payload and failing the filter.  Would ether[100] < tcp[100] test the \"ether and tcp\" conditions before checking the offsets, or would the conditions and the assertions be interleaved in some way?  (The ordering is indeed visible to the user.)  What if we swap the LHS and the RHS, is the result the same?  We need to do some science on the language to see what its semantics are in this regard.\r\n\r\nSee #166 for a symptom of this problem."},"comment":{"url":"https://api.github.com/repos/Igalia/pflua/issues/comments/95065585","html_url":"https://github.com/Igalia/pflua/issues/171#issuecomment-95065585","issue_url":"https://api.github.com/repos/Igalia/pflua/issues/171","id":95065585,"user":{"login":"andywingo","id":1745903,"avatar_url":"https://avatars.githubusercontent.com/u/1745903?v=3","gravatar_id":"","url":"https://api.github.com/users/andywingo","html_url":"https://github.com/andywingo","followers_url":"https://api.github.com/users/andywingo/followers","following_url":"https://api.github.com/users/andywingo/following{/other_user}","gists_url":"https://api.github.com/users/andywingo/gists{/gist_id}","starred_url":"https://api.github.com/users/andywingo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/andywingo/subscriptions","organizations_url":"https://api.github.com/users/andywingo/orgs","repos_url":"https://api.github.com/users/andywingo/repos","events_url":"https://api.github.com/users/andywingo/events{/privacy}","received_events_url":"https://api.github.com/users/andywingo/received_events","type":"User","site_admin":false},"created_at":"2015-04-22T07:51:22Z","updated_at":"2015-04-22T07:51:22Z","body":"Can we re-try with 2000 instead of 100 in all cases?  As far as I understand it, the point is to determine the order between out-of-bounds access (assertions) and protocol checks (conditionals).  Best to make sure that one of our offsets will definitely cause an OOB assertion, seems to me; and let's punt on the \"or tcp\" cases for now, just to narrow down the problem."}}