Proceedings of the 2018 Afternoon Workshop on Kernel Bypassing Networks 2018
DOI: 10.1145/3229538.3229540
|View full text |Cite
|
Sign up to set email alerts
|

A Formally Verified NAT Stack

Abstract: Prior work proved a stateful NAT network function to be semantically correct, crash-free, and memory safe [29]. Their toolchain verifies the network function code while assuming the underlying kernel-bypass framework, drivers, operating system, and hardware to be correct. We extend the toolchain to verify the kernel-bypass framework and a NIC driver in the context of the NAT. We uncover bugs in both the framework and the driver. Our code is publicly available [28].We patch DPDK to fix some bugs and make verifi… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1

Citation Types

0
2
0

Year Published

2019
2019
2020
2020

Publication Types

Select...
2
1

Relationship

1
2

Authors

Journals

citations
Cited by 3 publications
(2 citation statements)
references
References 3 publications
0
2
0
Order By: Relevance
“…To date, the relevant systems and methods are either (a) automatically tested but not formally verified, (b) use verification approaches which rely on automatic extraction from executable specifications (for example involving network stack synthesis [4], optimizing compilers [5], cryptographic libraries [6], and encoder/decoders [7]), or (c) apply a form of formal verification which only proves partial correctness properties (partial verification of NAT stack proving that only parts of DPDK are specification compliant [8], partial verification of Linux kernel TCP implementation with 55% line coverage and 92% protocol coverage [9]). Consequently, (a) and (c) do not provide sufficient correctness guarantees, while (b) is often impractical due to poor performance and compatibility limitations.…”
Section: Our Approachmentioning
confidence: 99%
“…To date, the relevant systems and methods are either (a) automatically tested but not formally verified, (b) use verification approaches which rely on automatic extraction from executable specifications (for example involving network stack synthesis [4], optimizing compilers [5], cryptographic libraries [6], and encoder/decoders [7]), or (c) apply a form of formal verification which only proves partial correctness properties (partial verification of NAT stack proving that only parts of DPDK are specification compliant [8], partial verification of Linux kernel TCP implementation with 55% line coverage and 92% protocol coverage [9]). Consequently, (a) and (c) do not provide sufficient correctness guarantees, while (b) is often impractical due to poor performance and compatibility limitations.…”
Section: Our Approachmentioning
confidence: 99%
“…Of the eight bugs we found in DPDK and the driver, six were confirmed by the DPDK maintainers and four have been fixed at the time of writing. We first reported these bugs in [38].…”
Section: Does Verification Have Tangible Benefits?mentioning
confidence: 99%