netdev - Re: [PATCH v2 net] net: mvpp2: Prevent parser TCAM memory corruption

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]

Message-ID: <87pliaa73x.fsf@waldekranz.com>
Date: Fri, 21 Mar 2025 13:41:38 +0100
From: Tobias Waldekranz <tobias@...dekranz.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: davem@...emloft.net, kuba@...nel.org, maxime.chevallier@...tlin.com,
 marcin.s.wojtas@...il.com, linux@...linux.org.uk, edumazet@...gle.com,
 pabeni@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2 net] net: mvpp2: Prevent parser TCAM memory corruption

On fre, mar 21, 2025 at 13:12, Andrew Lunn <andrew@...n.ch> wrote:
>> +static int mvpp2_prs_init_from_hw_unlocked(struct mvpp2 *priv,
>> +					   struct mvpp2_prs_entry *pe, int tid)
>>  {
>>  	int i;
>>  
>
> This is called from quite a few places, and the locking is not always
> obvious. Maybe add

Agreed, that was why i chose the _unlocked suffix vs. just prefixing
with _ or something. For sure I can add it, I just want to run something
by you first:

Originally, my idea was to just protect mvpp2_prs_init_from_hw() and
mvpp2_prs_hw_write(). Then I realized that the software shadow of the
SRAM table must also be protected, which is why locking had to be
hoisted up to the current scope.

> __must_hold(&priv->prs_spinlock)
>
> so sparse can verify the call paths ?

So if we add these asserts only to the hardware access leaf functions,
do we risk inadvertently signaling to future readers that the lock is
only there to protect the hardware tables?