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

Stefan Roese
2020-08-18T11:21:24Z

Hi Pali,

On 18.08.20 09:33, Pali Roh?r wrote:
> 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?

I'll try to think of it and add it to the commit text, when applying
this patch.

Thanks,
Stefan

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