OS-6884: viona frame headers risk TOCTOU

Details

Issue Type:Bug
Priority:4 - Normal
Status:Resolved
Created at:2018-04-10T23:39:39.850Z
Updated at:2018-09-21T14:03:12.373Z

People

Created by:Former user
Reported by:Former user
Assigned to:Former user

Resolution

Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2018-09-21T14:03:12.358Z)

Fix Versions

2018-09-27 Buzz Aldrin (Release Date: 2018-09-27)

Labels

bhyve

Description

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)

Comments

Comment by Former user
Created at 2018-09-20T22:33:46.681Z

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.


Comment by Jira Bot
Created at 2018-09-20T22:44:21.748Z

illumos-joyent commit 2b4a3b61df2d434e6512ab10225e77b1ab2396fa (branch master, by Ryan Zezeski)

OS-6884 viona frame headers risk TOCTOU