neutron

Bug #1797575
Comment #3

Comment 3 for bug 1797575

Revision history for this message

sean mooney (sean-k-mooney) wrote on 2018-12-03:

hi i unfortunately seam to have lost the analasys i did of this paper.

i will have to reconstruct it again but the TLDR that i remember is that
the paper does not provide a vialble workarount that neutron can implement
as it effectively would require a hardware change.

when considering if this is a viable exploit we also need to consider
hardware offloaded ovs.

for macvtap sriov we should be able to install an ntables filter to drop
all pause frames. for hardare offloaved ovs we should not need to if the implemented
flow control correctly but im not sure they have. we could add a drop rule to ovs also
for each vm port.

for vnic type direct phyical there is nothing neutron can do to filter out
pause frames however the data sheet for the nics they used state that only the PF can
send flow control messages which brings meaning vnic type direct should be if the PF is configred correctly which raises the question how they had configred the nics when doing there testing in the paper.

i will update this with future info related to ovs and the data sheet sections once i have a change to find the info again. it is unclear to me if this should be a neutron bug as the nics do have protections built into them to prevent this type of exploit which would indicate that this is either a hardware/firmware bug if present. assuming there is no firware bug its also possible that the nic was misconfigred or that the feature in the nic is not exposed/used by the dirver they used in testing.

so summary
- this could be a viable exploit.
- we may not be able to address this form openstack.
- it may require hardware/firmware change to address.
- the nic they used for testing has a feature to prevent this and its unclear if that was used.
- we may be able to implement a mitigation for vnic-type macvtap
- we cannot for vnic-type direct-physical
- for vnic-type direct we may be able to ensure the pf has flowcontol enable/disabeled from neutron
- this may also effect other backends that use sriov as a datapath such as hardware offloaded ovs.
- this would also affect nic passed through via nova falvor alias but those cannont be used with neutron so that is proably fine.

hi i unfortunately seam to have lost the analasys i did of this paper.

i will have to reconstruct it again but the TLDR that i remember is that
the paper does not provide a vialble workarount that neutron can implement
as it effectively would require a hardware change.

when considering if this is a viable exploit we also need to consider
hardware offloaded ovs.

for macvtap sriov we should be able to install an ntables filter to drop
all pause frames. for hardare offloaved ovs we should not need to if the implemented 
flow control correctly but im not sure they have. we could add a drop rule to ovs also
for each vm port.

so summary 
- this could be a viable exploit.
- we may not be able to address this form openstack.
- it may require hardware/firmware change to address.
- the nic they used for testing has a feature to prevent this and its unclear if that was used.
- we may be able to implement a mitigation for vnic-type macvtap
- we cannot for vnic-type direct-physical
- for vnic-type direct we may be able to ensure the pf has flowcontol enable/disabeled from neutron
- this may also effect other backends that use sriov as a datapath such as hardware offloaded ovs.
- this would also affect nic passed through via nova falvor alias but those cannont be used with neutron so that is proably fine.