Here's another test harness for connection tracking code. This is over
30x slower than the other two test cases (speed=2700 exec/s vs 85000
exec/s for the other two test cases). Just to clarify, I am not testing
on trunk (as I incorrectly claimed earlier). Rather, I am testing the
latest release v2.7.2.
====== target-ct.c =====
#include "flow.h"
#include "dp-packet.h"
#include "conntrack.h"
int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
{
struct conntrack ct;
conntrack_init(&ct);
struct dp_packet_batch pkt_batch;
struct flow flow;
struct dp_packet pkt;
dp_packet_use_const(&pkt, data, size);
packet_batch_init_packet(&pkt_batch, &pkt);
flow_extract(pkt_batch.packets[0], &flow);
conntrack_execute(&ct, &pkt_batch, flow.dl_type, true, 0, NULL,
NULL, NULL);
conntrack_destroy(&ct);
return 0;
}
====== target-ct.c =====
On 09/01/2017 02:04 PM, Bhargava Shastry wrote:
> Here is another test harness for fuzzing Openflow packet parsing on
> trunk. Feedback welcome!
>
> ===== target-ofp.c =====
>
> #include "flow.h"
> #include "dp-packet.h"
> #include "pcap-file.h"
> #include "odp-util.h"
>
> static bool
> is_openflow_port(ovs_be16 port_)
> {
> uint16_t port = ntohs(port_);
> return port == OFP_PORT || port == OFP_OLD_PORT;
> }
>
> int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
> {
> struct dp_packet packet;
> struct flow flow;
> struct tcp_reader *reader;
> dp_packet_use_const(&packet, data, size);
>
> pkt_metadata_init(&packet.md, ODPP_NONE);
> flow_extract(&packet, &flow);
> if (flow.dl_type == htons(ETH_TYPE_IP)
> && flow.nw_proto == IPPROTO_TCP
> && (is_openflow_port(flow.tp_src) ||
> is_openflow_port(flow.tp_dst))) {
> struct dp_packet *payload = tcp_reader_run(reader, &flow,
> &packet);
> if (payload) {
> while (dp_packet_size(payload) >= sizeof(struct
> ofp_header)) {
> const struct ofp_header *oh;
> void *pdata = dp_packet_data(payload);
> int length;
>
> /* Align OpenFlow on 8-byte boundary for safe access. */
> dp_packet_shift(payload, -((intptr_t) pdata & 7));
>
> oh = dp_packet_data(payload);
> length = ntohs(oh->length);
> if (dp_packet_size(payload) < length) {
> break;
> }
>
> ofp_print(stdout, dp_packet_data(payload), length, 4);
> dp_packet_pull(payload, length);
> }
> }
> tcp_reader_close(reader);
> }
> return 0;
> }
>
> ===== target-ofp.c =====
>
> P.S. Fuzzing for ~10h didn't result in anything. Test coverage saturates
> early but that's possibly because this isn't doing any deep processing.
>
> Regards,
> Bhargava
>
> On 08/31/2017 11:18 PM, Kostya Serebryany wrote:
>> For the version Bhargava is testing I guess this reads as
>> int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
>> {
>> struct ofpbuf packet;
>> ofpbuf_use_const(&packet, data, size);
>>
>> struct flow flow;
>>
>> flow_extract(&packet, NULL, &flow);
>>
>> return 0;
>> }
>>
>> Looks great, and runs fast.
>>
>>
>> On Thu, Aug 31, 2017 at 2:05 PM, Bhargava Shastry
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi,
>>
>> > I didn't look at the actual code before, but now that I have, I don't
>> > understand at all why it was doing file I/O just to write a packet to
>> > disk and then read it back.
>>
>> Sorry, this was due to my ignorance. I was not aware of something like
>> dp_packet_use_const(). This should speed things up. I am working on it.
>>
>> >
>> > Here is a more natural way to do this:
>> >
>> > int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
>> > {
>> > struct dp_packet packet;
>> > dp_packet_use_const(&packet, data, size);
>> >
>> > struct flow flow;
>> > flow_extract(&packet, &flow);
>> >
>> > return 0;
>> > }
>> >
>>
>> --
>> Bhargava Shastry <[email protected]
>> <mailto:[email protected]>>
>> Security in Telecommunications
>> TU Berlin / Telekom Innovation Laboratories
>> Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
>> phone: +49 30 8353 58235 <tel:%2B49%2030%208353%2058235>
>> Keybase: https://keybase.io/bshastry
>>
>>
>
--
Bhargava Shastry <[email protected]>
Security in Telecommunications
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
phone: +49 30 8353 58235
Keybase: https://keybase.io/bshastry
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
