Message-ID: <20180713144608.GB2875@kwain>
Date:   Fri, 13 Jul 2018 16:46:08 +0200
From:   Antoine Tenart <antoine.tenart@...tlin.com>
To:     davem@...emloft.net, sd@...asysnail.net, f.fainelli@...il.com,
        andrew@...n.ch
Cc:     thomas.petazzoni@...tlin.com, alexandre.belloni@...tlin.com,
        allan.nielsen@...rosemi.com, netdev@...r.kernel.org
Subject: MACsec hardware offloading

Hello,

Linux has a software implementation of the MACsec standard but so far,
to my knowledge, no hardware offloading support was developed and sent
upstream. I am working on a PHY that has an embedded MACsec engine and
would like to add support for MACsec hardware offloading in Linux in
order to support this PHY capability.

If you think I'm missing someone who would be interested in
participating to the discussion, please feel free to Cc her/him.

My main idea would be to reuse and leverage the actual software
implementation in Linux. The advantages would be to reuse existing code,
data structure and to configure this using the exact same tools from
user-space. Also the MACsec state could be kept in the software
implementation (as it's done now), with stateless hardware ops.
Those hooks would be called from the (at least) genl_ops of the
software implementation.

I made a very simple and early version, more to get an idea of what
needed to be done than to actually having something ready, at:
https://github.com/atenart/linux/commit/2dc30abb2d349402ac78a851de09d6e0791e7bf1

One important point about adding MACsec offloading in Linux is this can
be done in either the MAC or the PHY. While I'll be working on making
this work in a PHY, I know for sure some MAC do have the same capability
(including for example the Intel ixgbe NIC). This means the offloading
interface should be done for both those devices in mind. It also means
we can have cases were for a given link both the PHY and the MAC have
the MACsec offloading capability. We'll probably have to make this a
runtime configuration option, so that the user can chose which of the
three implementation is responsible of the MACsec operations (PHY, MAC
or software). (We can also think of cases were different security
associations could be handled by different layers).

This is the design I have in mind. As of now I mainly worked on my PHY
hardware initialization and configuration (and still have work to do)
but I think it's time to discuss as well the generic MACsec offloading
plan as well. I'd love to have your opinion and suggestions, whether
you think this is the right approach or not.

I also do have some open questions:

- When having more than a single MACsec h/w offloading provider (say a
  network engine and a PHY), there probably should be a way to decide
  which one to use. The s/w implementation should be part of this choice
  as well. I'm not sure how to do this and what should be the default
  setting.

  The users will also want to switch the layer being used to handle a
  particular security association, or to move all the associations to
  a given layer, at runtime.

- The MACsec representation to the user is a virtual interface. When
  using the s/w implementation it's easy to know when to use MACsec on
  the frames: it depends on which interface is used (the MACsec virtual
  one, or the physical one, or another virtual interface not being a
  child to the MACsec one). But with h/w offloading (at least when it's
  done at the PHY level), it's impossible to know onto which interface
  the frame was injected. This could be an issue as some frames might
  need to be sent without the MACsec layer doing anything.

Thanks a lot!
Antoine

-- 
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists