Hi, Any thoughts on the proposal I made? The bugs libFuzzer has helped find recently makes a compelling case to integrate OvS with oss-fuzz.
Regards, Bhargava On 09/01/2017 05:31 PM, Bhargava Shastry wrote: > Dear all, > > I suppose the following are the agenda points for adding OvS to OSS-Fuzz. > > 1. [Easy] Write Docker file for getting OvS to build. Feel this should > be easy as I don't see any non-default dependencies > > 2. [Easy] Add a project.yaml that documents project metadata such as > contact persons, project homepage etc. > > 3. [Medium] Add a build script to get OSS tests to compile. > > 4. [Medium] Add relevant OSS tests to OvS trunk/branch. These tests > should ideally cover 100% of the codebase but we most likely start with > a handful I guess. The tests that uncovered CVEs in OvS over previous > months is a good starting point? > > dev@OvS is best equipped to handle (1) and (2). As for (3) and (4), you > could use my commit here [1] as a starting point. Like I said, I am > happy to help write more tests with oversight from dev@OvS/KCC. Let me > know how this plan sounds. BTW, here is a reference OSS-Fuzz template > from Wireshark [2] that you could use I guess. > > [1]: > https://github.com/bshastry/fuzzer-test-suite/tree/master/openvswitch-2.7.2 > [2]: https://github.com/google/oss-fuzz/tree/master/projects/wireshark > > Regards, > Bhargava > > On 09/01/2017 03:16 PM, Bhargava Shastry wrote: >> 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 >>>> <bshas...@sec.t-labs.tu-berlin.de >>>> <mailto:bshas...@sec.t-labs.tu-berlin.de>> 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 <bshas...@sec.t-labs.tu-berlin.de >>>> <mailto:bshas...@sec.t-labs.tu-berlin.de>> >>>> 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 <bshas...@sec.t-labs.tu-berlin.de> 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 d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
