MACsec hardware offloading

MACsec hardware offloading

[Antoine Tenart]

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

Re: MACsec hardware offloading

[Andrew Lunn]

On Fri, Jul 13, 2018 at 04:46:08PM +0200, Antoine Tenart wrote:
> 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.

Mellonex is usually the leader in this sort of thing. Adding Jiri to
Cc: However, they often do their PHY control in firmware, rather than
using Linux.

> 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.

I fully agree with this approach. That is how we do all other
offloading to accelerators.

> 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).

I see in your current code, you check if the netdev has a phydev, and
if the phydev supports macsec, and then go straight to the phy. That
means there is no need to modify the MAC driver, it should just work.
If not, you call the MAC.

I would add support for the PHY to return -EOPNOTSUPP and then fall
back to trying the MAC.

Also, your current checks are
inconsistent. macsec_hw_offload_capable() checks for
phydev->drv->macsec, where as macsec_hw_offload() just checks for
dev->real_dev->phydev->drv. It looks like
dev->real_dev->phydev->drv->macsec could be a NULL pointer and bad
things happen.

For switchdev, when we offload to a switch, the switch nearly always
has the option to say it could not accept the offload. We then fall
back to performing the needed action in software. At the moment, i
don't see you checking the return code of macsec_hw_offload(). So it
is not clear to me if this software fallback works.

The Switchdev API is also transaction based, with a prepare and a
commit phase. All resource allocation happens in the prepare phase and
at this stage, you can return errors indicating offload is not
possible. The commit phase is not allowed to fail. You probably want
to go look at the mailing list archive and look at why this
architecture was decided on.

Maybe the MAC part of this should actually use the switchdev API?  You
then get a lot of infrastructure for free.

     Andrew

Re: MACsec hardware offloading

[Antoine Tenart]

Hi Andrew,

On Fri, Jul 13, 2018 at 06:20:02PM +0200, Andrew Lunn wrote:
> On Fri, Jul 13, 2018 at 04:46:08PM +0200, Antoine Tenart wrote:
> 
> > 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).
> 
> I see in your current code, you check if the netdev has a phydev, and
> if the phydev supports macsec, and then go straight to the phy. That
> means there is no need to modify the MAC driver, it should just work.
> If not, you call the MAC.

Yes. I'm just not sure if the PHY implementation should have precedence
over the MAC one, or the opposite, or if the user should be able to
select the provider to use.

> I would add support for the PHY to return -EOPNOTSUPP and then fall
> back to trying the MAC.

Good idea!

> Also, your current checks are
> inconsistent. macsec_hw_offload_capable() checks for
> phydev->drv->macsec, where as macsec_hw_offload() just checks for
> dev->real_dev->phydev->drv. It looks like
> dev->real_dev->phydev->drv->macsec could be a NULL pointer and bad
> things happen.

OK, I'll be careful and fix this.

> For switchdev, when we offload to a switch, the switch nearly always
> has the option to say it could not accept the offload. We then fall
> back to performing the needed action in software. At the moment, i
> don't see you checking the return code of macsec_hw_offload(). So it
> is not clear to me if this software fallback works.

Right, that should be supported. Although I'm not sure all offloading
helpers can have a fallback (especially if they depend on a previous
one), but I'll try to have this kind of behaviour in place whenever
possible. Or maybe it'll just work for all helpers, as the MACsec state
will always be kept in the software implementation part.

> The Switchdev API is also transaction based, with a prepare and a
> commit phase. All resource allocation happens in the prepare phase and
> at this stage, you can return errors indicating offload is not
> possible. The commit phase is not allowed to fail. You probably want
> to go look at the mailing list archive and look at why this
> architecture was decided on.

Thanks for the hint, I'll have a look at this design pattern.

> Maybe the MAC part of this should actually use the switchdev API?  You
> then get a lot of infrastructure for free.

I'll have a look at this as well. With the prepare/commit logic already
in place, it could be easier to implement.

Thanks!
Antoine

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