[PATCH] arm: mvebu: Espressobin: Disallow forwarding packets between wan and lan ports

[Pali Rohár]

CCing Konstantin, you may have be interested in my following Espressobin patch.

BTW, ./scripts/get_maintainer.pl does not shows you as maintainer of
board/Marvell/mvebu_armada-37xx/board.c file, even it contains
Espressobin specific code.

On Tuesday 18 August 2020 07:26:36 Stefan Roese wrote:
> On 17.08.20 16:36, Pali Rohár wrote:
> > By default Topaz switch on Espressobin board forwards packets between all
> > ethernet ports, including CPU (port 0), wan (port 1) and lan (ports 2,3).
> > 
> > This default U-Boot setup is unsuitable for using Espressobin as router as
> > it opens security hole in forwarding all packets between wan and lan ports.
> > E.g. dhcp packets from wan network leaks to lan network during small time
> > window until U-Boot boots Linux kernel which loads network drivers which
> > disallows forwarding between wan and lan.
> > 
> > This patch fixes above problem. For Espressobin board prior putting Topaz
> > switch into forwarding mode, Topaz switch is reconfigured to allow
> > forwarding packets from wan and lan ports only to CPU port. This ensures
> > that packets from wan port are not forwarded to lan ports and vice-versa.
> > Packets from CPU port are still forwarded to all other ports, so U-Boot
> > network boot works with any ethernet port as before.
> > 
> > This problem was already discussed on Espressobin forum [1] and on
> > Marvell's github issue tracker [2]. As a workaround people on Espressobin
> > forum patched U-Boot to completely disable lan ports on Topaz switch which
> > prevented forwarding packets. That workaround had an issue that U-Boot was
> > unable to netboot via lan ports anymore. Change in this patch does not have
> > such issue.
> > 
> > [1] - https://web.archive.org/web/20191231164238/http://espressobin.net/forums/topic/boot-behavior-of-the-switch-and-security/
> > [2] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/issues/18

FYI there is another forum thread [3] where people are applying another
"dirty workaround" for this Espressobin issue:

[3] - https://forum.armbian.com/topic/12635-espressobin-uboot-security-concerns-switch-init-portmask/

> > Signed-off-by: Pali Rohár <pali at kernel.org>
> 
> Reviewed-by: Stefan Roese <sr at denx.de>
> 
> Thanks,
> Stefan

Stefan, would like to put above armbian forum reference to commit
message too?

> > ---
> >   board/Marvell/mvebu_armada-37xx/board.c | 9 +++++++++
> >   1 file changed, 9 insertions(+)
> > 
> > diff --git a/board/Marvell/mvebu_armada-37xx/board.c b/board/Marvell/mvebu_armada-37xx/board.c
> > index 9bea1986d4..031de318c6 100644
> > --- a/board/Marvell/mvebu_armada-37xx/board.c
> > +++ b/board/Marvell/mvebu_armada-37xx/board.c
> > @@ -37,20 +37,21 @@ DECLARE_GLOBAL_DATA_PTR;
> >    #define SW_SMI_CMD_REG_ADDR_OFF	0
> >    #define SW_SMI_CMD_DEV_ADDR_OFF	5
> >    #define SW_SMI_CMD_SMI_OP_OFF		10
> >    #define SW_SMI_CMD_SMI_MODE_OFF	12
> >    #define SW_SMI_CMD_SMI_BUSY_OFF	15
> >   /* Single-chip mode */
> >   /* Switch Port Registers */
> >   #define MVEBU_SW_LINK_CTRL_REG		(1)
> >   #define MVEBU_SW_PORT_CTRL_REG		(4)
> > +#define MVEBU_SW_PORT_BASE_VLAN		(6)
> >   /* Global 2 Registers */
> >   #define MVEBU_G2_SMI_PHY_CMD_REG	(24)
> >   #define MVEBU_G2_SMI_PHY_DATA_REG	(25)
> >   int board_early_init_f(void)
> >   {
> >   	return 0;
> >   }
> > @@ -200,22 +201,30 @@ static int mii_multi_chip_mode_write(struct mii_dev *bus, int dev_smi_addr,
> >   /* Bring-up board-specific network stuff */
> >   int board_network_enable(struct mii_dev *bus)
> >   {
> >   	if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
> >   		return 0;
> >   	/*
> >   	 * FIXME: remove this code once Topaz driver gets available
> >   	 * A3720 Community Board Only
> >   	 * Configure Topaz switch (88E6341)
> > +	 * Restrict output to ports 1,2,3 only from port 0 (CPU)
> >   	 * Set port 0,1,2,3 to forwarding Mode (through Switch Port registers)
> >   	 */
> > +	mii_multi_chip_mode_write(bus, 1, MVEBU_PORT_CTRL_SMI_ADDR(1),
> > +				  MVEBU_SW_PORT_BASE_VLAN, BIT(0));
> > +	mii_multi_chip_mode_write(bus, 1, MVEBU_PORT_CTRL_SMI_ADDR(2),
> > +				  MVEBU_SW_PORT_BASE_VLAN, BIT(0));
> > +	mii_multi_chip_mode_write(bus, 1, MVEBU_PORT_CTRL_SMI_ADDR(3),
> > +				  MVEBU_SW_PORT_BASE_VLAN, BIT(0));
> > +
> >   	mii_multi_chip_mode_write(bus, 1, MVEBU_PORT_CTRL_SMI_ADDR(0),
> >   				  MVEBU_SW_PORT_CTRL_REG, 0x7f);
> >   	mii_multi_chip_mode_write(bus, 1, MVEBU_PORT_CTRL_SMI_ADDR(1),
> >   				  MVEBU_SW_PORT_CTRL_REG, 0x7f);
> >   	mii_multi_chip_mode_write(bus, 1, MVEBU_PORT_CTRL_SMI_ADDR(2),
> >   				  MVEBU_SW_PORT_CTRL_REG, 0x7f);
> >   	mii_multi_chip_mode_write(bus, 1, MVEBU_PORT_CTRL_SMI_ADDR(3),
> >   				  MVEBU_SW_PORT_CTRL_REG, 0x7f);
> >   	/* RGMII Delay on Port 0 (CPU port), force link to 1000Mbps */
> > 
> 
> 
> Viele Grüße,
> Stefan
> 
> -- 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de