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

Pali Rohár
2020-08-18T07:33:46Z

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@kernel.org>
>
> Reviewed-by: Stefan Roese <sr@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