Issue Type: | Bug |
---|---|
Priority: | 4 - Normal |
Status: | Resolved |
Created at: | 2018-04-10T23:39:39.850Z |
Updated at: | 2018-09-21T14:03:12.373Z |
Created by: | Former user |
---|---|
Reported by: | Former user |
Assigned to: | Former user |
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2018-09-21T14:03:12.358Z)
2018-09-27 Buzz Aldrin (Release Date: 2018-09-27)
When transmitting data from the guest, viona wraps the buffers directly in an mblk_t
(via desballoc
) whenever possible. This means that the L2/L3/L4 headers are all back by memory controlled by the guest. Since those headers are consulted later by MAC during anti-spoof checks, they could be subject to a TOCTOU bug. The guest could present a packet which passes anti-spoof, only to switch the src/dst addresses before the mblk arrives at the NIC to be sent. The timing is delicate, but in the face of practically free failure, persistence would pay off.
To combat this, viona should pull-up the headers into a separate mblk. This is useful for later tasks such as TSO, checksumming, and/or VLAN/VXLAN encap. (The buffer is writable and can include enough free margin to avoid additional allocations for later value-add operations)
I tested this by running iperf benchmarks in both directions between a bhyve zone and native zone. Sometimes the iperf performance was worse than before, sometimes it was better. As I've seen in the past with iperf benchmarks on SmartOS -- it seems to depend greatly on which CPUs things happen to land on.
illumos-joyent commit 2b4a3b61df2d434e6512ab10225e77b1ab2396fa (branch master, by Ryan Zezeski)
OS-6884 viona frame headers risk TOCTOU