kernel/linux.git/drivers/net/phy/mscc/mscc_macsec.c, branch v6.2

net: phy: mscc: macsec: do not copy encryption keys

2022-11-18T09:17:42+00:00

Following 1b16b3fdf675 ("net: phy: mscc: macsec: clear encryption keys when freeing a flow"), go one step further and instead of calling memzero_explicit on the key when freeing a flow, simply not copy the key in the first place as it's only used when a new flow is set up. Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller

net: phy: mscc: macsec: clear encryption keys when freeing a flow

2022-11-10T10:58:52+00:00

Commit aaab73f8fba4 ("macsec: clear encryption keys from the stack after setting up offload") made sure to clean encryption keys from the stack after setting up offloading, but the MSCC PHY driver made a copy, kept it in the flow data and did not clear it when freeing a flow. Fix this. Fixes: 28c5107aa904 ("net: phy: mscc: macsec support") Signed-off-by: Antoine Tenart Signed-off-by: Paolo Abeni

net: phy: mscc: macsec: remove checks on the prepare phase

2022-09-23T13:56:08+00:00

Remove checks on the prepare phase as it is now unused by the MACsec core implementation. Signed-off-by: Antoine Tenart Signed-off-by: Jakub Kicinski

net: phy: mscc: macsec: make the prepare phase a noop

2022-09-23T13:56:07+00:00

In preparation for removing the MACsec h/w offloading preparation phase, make it a no-op in the MSCC phy driver. Signed-off-by: Antoine Tenart Signed-off-by: Jakub Kicinski

net: phy: mscc: fix macsec key length

2021-06-24T19:41:12+00:00

The key length used to store the macsec key was set to MACSEC_KEYID_LEN (16), which is an issue as: - This was never meant to be the key length. - The key length can be > 16. Fix this by using MACSEC_MAX_KEY_LEN instead (the max length accepted in uAPI). Fixes: 28c5107aa904 ("net: phy: mscc: macsec support") Reported-by: Lior Nahmanson Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller

net: phy: mscc: remove non-MACSec compatible phy

2020-11-13T23:08:07+00:00

Selecting VSC8575 as a MACSec PHY was not correct The relevant datasheet can be found here: - VSC8575: https://www.microchip.com/wwwproducts/en/VSC8575 History: v1 -> v2: - Corrected the sha in the "Fixes:" tag Fixes: 1bbe0ecc2a1a ("net: phy: mscc: macsec initialization") Signed-off-by: Steen Hegelund Reviewed-by: Antoine Tenart Link: https://lore.kernel.org/r/20201113091116.1102450-1-steen.hegelund@microchip.com Signed-off-by: Jakub Kicinski

net: phy: mscc: macsec: constify vsc8584_macsec_ops

2020-08-26T23:21:17+00:00

The only usage of vsc8584_macsec_ops is to assign its address to the macsec_ops field in the phydev struct, which is a const pointer. Make it const to allow the compiler to put it in read-only memory. Signed-off-by: Rikard Falkeborn Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2020-06-26T02:29:51+00:00

Minor overlapping changes in xfrm_device.c, between the double ESP trailing bug fix setting the XFRM_INIT flag and the changes in net-next preparing for bonding encryption support. Signed-off-by: David S. Miller

net: phy: mscc: macsec: fix sparse warnings

2020-06-25T23:22:10+00:00

This patch fixes the following sparse warnings when building MACsec support in the MSCC PHY driver. mscc_macsec.c:393:42: warning: cast from restricted sci_t mscc_macsec.c:395:42: warning: restricted sci_t degrades to integer mscc_macsec.c:402:42: warning: restricted __be16 degrades to integer mscc_macsec.c:608:34: warning: cast from restricted sci_t mscc_macsec.c:610:34: warning: restricted sci_t degrades to integer Signed-off-by: Antoine Tenart Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

net: phy: mscc: avoid skcipher API for single block AES encryption

2020-06-25T19:16:14+00:00

The skcipher API dynamically instantiates the transformation object on request that implements the requested algorithm optimally on the given platform. This notion of optimality only matters for cases like bulk network or disk encryption, where performance can be a bottleneck, or in cases where the algorithm itself is not known at compile time. In the mscc case, we are dealing with AES encryption of a single block, and so neither concern applies, and we are better off using the AES library interface, which is lightweight and safe for this kind of use. Note that the scatterlist API does not permit references to buffers that are located on the stack, so the existing code is incorrect in any case, but avoiding the skcipher and scatterlist APIs entirely is the most straight-forward approach to fixing this. Cc: Antoine Tenart Cc: Andrew Lunn Cc: Florian Fainelli Cc: Heiner Kallweit Cc: "David S. Miller" Cc: Jakub Kicinski Fixes: 28c5107aa904e ("net: phy: mscc: macsec support") Reviewed-by: Eric Biggers Signed-off-by: Ard Biesheuvel Tested-by: Antoine Tenart Signed-off-by: David S. Miller