Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure
Hi, I can add some information to the HW Antoine is working on, general design of it and the thoughts behind it. See below. The 08/20/2019 16:41, Sabrina Dubroca wrote: > 2019-08-20, 12:01:40 +0200, Antoine Tenart wrote: > > So it seems the ability to enable or disable the offloading on a given > > interface is the main missing feature. I'll add that, however I'll > > probably (at least at first): > > > > - Have the interface to be fully offloaded or fully handled in s/w (with > > errors being thrown if a given configuration isn't supported). Having > > both at the same time on a given interface would be tricky because of > > the MACsec validation parameter. > > > > - Won't allow to enable/disable the offloading of there are rules in > > place, as we're not sure the same rules would be accepted by the other > > implementation. > > That's probably quite problematic actually, because to do that you > need to be able to resync the state between software and hardware, > particularly packet numbers. So, yeah, we're better off having it > completely blocked until we have a working implementation (if that > ever happens). > > However, that means in case the user wants to set up something that's > not offloadable, they'll have to: > - configure the offloaded version until EOPNOTSUPP > - tear everything down > - restart from scratch without offloading > > That's inconvenient. > > Talking about packet numbers, can you describe how PN exhaustion is > handled? I couldn't find much about packet numbers at all in the > driver patches (I hope the hw doesn't wrap around from 2^32-1 to 0 on > the same SA). New SA's are suppose to be installed ahead of time. The HW will automatic move to the next SA and reset the PN. > At some point userspace needs to know that we're > getting close to 2^32 and that it's time to re-key. Since the whole > TX path of the software implementation is bypassed, it looks like the > PN (as far as drivers/net/macsec.c is concerned) never increases, so > userspace can't know when to negotiate a new SA. > > > I'm not sure if we should allow to mix the implementations on a given > > physical interface (by having two MACsec interfaces attached) as the > > validation would be impossible to do (we would have no idea if a > > packet was correctly handled by the offloading part or just not being > > a MACsec packet in the first place, in Rx). > > That's something that really bothers me with this proposal. Quoting > from the commit message: > > > the packets seen by the networking stack on both the physical and > > MACsec virtual interface are exactly the same > > If the HW/driver is expected to strip the sectag, I don't see how we > could ever have multiple secy's at the same time and demultiplex > properly between them. That's part of the reason why I chose to have > virtual interfaces: without them, picking the right secy on TX gets > weird. The HW does frame clasification, and use the claisfication to associate frames to a given secy. We we in SW have eth0, with 2 vlan-sub interfaces, and enable macsec on those, then we have: eth0 eth0.10 eth0.10.macsec eth0.20 eth0.20.macsec In this case the HW needs to be configured to match vlan 10 to one secy, and vlan 20 to an other one. This is nor supported in the current patch, but is something we can add later. We just wanted to get the basic functionallity done right before moving on to this. But in the current design, there is nothing that prevent us from adding this. If anyone is interested in the details of this then it is described in section 3.6.3 in http://ww1.microchip.com/downloads/en/DeviceDoc/VMDS-10455.pdf It is possible to construct an encapsulation that the HW can not classify correctly. If that is the case, then we should reject the HW offload, and use the SW. But it is a good point, which I think is missing. We should properly reject MACsec HW offload (with this driver, in this state) on virtual interfaces, if the encapsulation can not be handled (could start by reject all virtual interfaces) > AFAICT, it means that any filters (tc, tcpdump) need to be different > between offloaded and non-offloaded cases. It will see the result of the offloaded operation. But I guess that this is no different from when 'tc' operations are offloaded to HW. > How does the driver distinguish traffic that should pass through unmodified > from traffic that the HW needs to encapsulate and encrypt? It relay on frame classification (I think Antoine is missing a flow configuration to bypass all MKA traffic). > If you look at IPsec offloading, the networking stack builds up the > ESP header, and passes the unencrypted data down to the driver. I'm > wondering if the same would be possible with MACsec offloading: the > macsec virtual interface adds the header (and maybe a dummy ICV), and > then the HW does the encryption. In case of HW that needs to add the > sectag itself, the driver would first strip the headers that the stack > cre
Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure
The 08/21/2019 09:20, Igor Russkikh wrote: > > Talking about packet numbers, can you describe how PN exhaustion is > > handled? I couldn't find much about packet numbers at all in the > > driver patches (I hope the hw doesn't wrap around from 2^32-1 to 0 on > > the same SA). At some point userspace needs to know that we're > > getting close to 2^32 and that it's time to re-key. Since the whole > > TX path of the software implementation is bypassed, it looks like the > > PN (as far as drivers/net/macsec.c is concerned) never increases, so > > userspace can't know when to negotiate a new SA. > > I think there should be driver specific implementation of this functionality. > As an example, our macsec HW issues an interrupt towards the host to indicate > PN threshold has reached and it's time for userspace to change the keys. > > In contrast, current SW macsec implementation just stops this SA/secy. > > > I don't see how this implementation handles non-macsec traffic (on TX, > > that would be packets sent directly through the real interface, for > > example by wpa_supplicant - on RX, incoming MKA traffic for > > wpa_supplicant). Unless I missed something, incoming MKA traffic will > > end up on the macsec interface as well as the lower interface (not > > entirely critical, as long as wpa_supplicant can grab it on the lower > > device, but not consistent with the software implementation). How does > > the driver distinguish traffic that should pass through unmodified > > from traffic that the HW needs to encapsulate and encrypt? > > I can comment on our HW engine - where it has special bypass rules > for configured ethertypes. This way macsec engine skips encryption on TX and > passes in RX unencrypted for the selected control packets. In our case it is a TCAM which can look at various fields (including ethertype), but is sounds like we have a vary similar design. > But thats true, realdev driver is hard to distinguish encrypted/unencrypted > packets. In case realdev should make a decision where to put RX packet, > it only may do some heuristic (since after macsec decription all the > macsec related info is dropped. Thats true at least for our HW > implementation). Same for ours. > > If you look at IPsec offloading, the networking stack builds up the > > ESP header, and passes the unencrypted data down to the driver. I'm > > wondering if the same would be possible with MACsec offloading: the > > macsec virtual interface adds the header (and maybe a dummy ICV), and > > then the HW does the encryption. In case of HW that needs to add the > > sectag itself, the driver would first strip the headers that the stack > > created. On receive, the driver would recreate a sectag and the macsec > > interface would just skip all verification (decrypt, PN). > > I don't think this way is good, as driver have to do per packet header > mangling. > That'll harm linerate performance heavily. Agree, and it will also prevent MACsec offload in offloaded bridge devices. /Allan
Re: [net-next v2 10/11] bridge: switchdev: cfm: switchdev interface implementation
On 06.10.2020 10:50, Nikolay Aleksandrov wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On Mon, 2020-10-05 at 15:07 +0200, Allan W. Nielsen wrote: Hi Jiri On 01.10.2020 14:49, Jiri Pirko wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Thu, Oct 01, 2020 at 12:30:18PM CEST, henrik.bjoernl...@microchip.com wrote: > > This is the definition of the CFM switchdev interface. > > > > The interface consist of these objects: > >SWITCHDEV_OBJ_ID_MEP_CFM, > >SWITCHDEV_OBJ_ID_MEP_CONFIG_CFM, > >SWITCHDEV_OBJ_ID_CC_CONFIG_CFM, > >SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM, > >SWITCHDEV_OBJ_ID_CC_CCM_TX_CFM, > >SWITCHDEV_OBJ_ID_MEP_STATUS_CFM, > >SWITCHDEV_OBJ_ID_PEER_MEP_STATUS_CFM > > > > MEP instance add/del > >switchdev_port_obj_add(SWITCHDEV_OBJ_ID_MEP_CFM) > >switchdev_port_obj_del(SWITCHDEV_OBJ_ID_MEP_CFM) > > > > MEP cofigure > >switchdev_port_obj_add(SWITCHDEV_OBJ_ID_MEP_CONFIG_CFM) > > > > MEP CC cofigure > >switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_CONFIG_CFM) > > > > Peer MEP add/del > >switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM) > >switchdev_port_obj_del(SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM) > > > > Start/stop CCM transmission > >switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_CCM_TX_CFM) > > > > Get MEP status > > switchdev_port_obj_get(SWITCHDEV_OBJ_ID_MEP_STATUS_CFM) > > > > Get Peer MEP status > > switchdev_port_obj_get(SWITCHDEV_OBJ_ID_PEER_MEP_STATUS_CFM) > > > > Reviewed-by: Horatiu Vultur > > Signed-off-by: Henrik Bjoernlund > > You have to submit the driver parts as a part of this patchset. > Otherwise it is no good. Fair enough. With MRP we did it like this, and after Nik asked for details on what is being offload, we thought that adding this would help. The reason why we did not include the implementation of this interface is that it is for a new SoC which is still not fully available which is why we have not done the basic SwitchDev driver for it yet. But the basic functionality clearly needs to come first. Our preference is to continue fixing the comments we got on the pure SW implementation and then get back to the SwitchDev offloading. This will mean dropping the last 2 patches in the serie. Does that work for you Jiri, and Nik? /Allan Sounds good to me. Sorry I was unresponsive last week, but I was sick and couldn't get to netdev@. I'll review the set today. Perfect. Thanks for the support. /Allan
