linux-kernel - Re: [PATCH v2] net: dsa: tag_mtk: add padding for tx packets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 May 2022 15:08:05 +0200
From:   Felix Fietkau <nbd@....name>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net: dsa: tag_mtk: add padding for tx packets


Hi Andrew,

On 12.05.22 14:39, Andrew Lunn wrote:
>> I just ran some more tests, here's what I found:
>> The switch automatically pads all forwarded packets to 64 bytes.
>> When packets are forwarded from one external port to another, the padding is
>> all zero.
>> Only when packets are sent from a CPU port to an external port, the last 4
>> bytes contain garbage. The garbage bytes are different for every packet, and
>> I can't tell if it's leaking contents of previous packets or what else is in
>> there.
>> Based on that, I'm pretty sure that the hardware simply has a quirk where it
>> does not account for the special tag when generating its own padding
>> internally.
> 
> This does not yet explain why your receiver is dropping the frame. As
> Vladimir pointed out, the contents of the pad should not matter.
> 
> Is it also getting the FCS wrong when it pads? That would cause the
> receiver to drop the frame.
> 
> Or do we have an issue in the receiver where it is looking at the
> contents of the pad?
On the devices that I used for testing before, FCS wasn't reported in my 
captures. Since I can't reproduce the issue of the receiver dropping 
frames anymore, I currently have no way of figuring out what went wrong.

When I was able to reproduce the issue, I'm sure that I switched between 
patched and unpatched builds a few times to make sure that my change 
actually made a difference, which it did.

I do agree that having the garbage bytes in there is technically 
compliant with the spec. On the other hand, based on my observations I 
believe that the hardware's behavior of filling the last 4 bytes with 
seemingly random values only in the case of small frames being sent with 
a CPU special tag is clearly not intentional nor by design.

The issue is also clearly limited to processing packets with the tag 
(which can only come from the CPU), so in my opinion the tag driver is 
the right place to deal with it.

So I guess it comes down to whether you guys think that this is worth 
fixing.

I still consider it worth fixing, because:
- It looks like a hardware bug to me with potentially unknown consequences.
- If it caused issues in my setup, it might do so in other people's 
setups as well.
- I can't rule out potential information leakage from those 4 bytes

I guess if you guys don't think the issue is worth the price of a very 
small performance hit from padding the packets, I will just have to keep 
this as an out-of-tree patch.

- Felix